From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by sourceware.org (Postfix) with ESMTPS id A667B385EC55 for ; Fri, 25 Sep 2020 16:30:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A667B385EC55 Received: by mail-wr1-x441.google.com with SMTP id k10so1131573wru.6 for ; Fri, 25 Sep 2020 09:30:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4jdg6HluSD0IAXD+xCNl8iJ0heD5lzYJS/e0fwkN9Ko=; b=m/afJYKu6GzE08NPSw8rQKxac7GdwVtMDTTin/cM1tk7gMQoeAji8Hsc2cljtnm+uy W3cgBj2aQpC53z//JaCvTT0x0xpIyqPSznZ3d6JqsHHDl2QopCuc3hvhvMTgqc28G1Hn Js0E/mhmkMjFgt7VhqhQ0W59YEd9LmjyQYuWg6F/TZf1TbUpqyPtGfz5bjtckU1t+DHm lxSLIdveDULE4MMObbK3+x8svp2tFg7ynoXuDCgO2UwX4J9CsyzulX6hSO6mdn88Jzzv CGNEK8xlOyhO2ZKjy0wc6S2l8V4QhupxB2EUCZoJd1w1gZ3YZzink70DPNZj010I8Dlo Xecw== X-Gm-Message-State: AOAM533ec4rsCH1kd4Gc0c/t8kqxj6kgL6GoIc+/WZSBb04fQ5Dq9ym7 h/zBuEMPbaU+c9GizPvvTxQ= X-Google-Smtp-Source: ABdhPJwUYMkkzTAcy3o+2DS9BEZxnAyPQJfcTA1zfupyyyVTxpoOPurKoyhF0HOL9AigWj18wG4/2g== X-Received: by 2002:a5d:444b:: with SMTP id x11mr5353193wrr.402.1601051430708; Fri, 25 Sep 2020 09:30:30 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id n3sm3439469wmn.28.2020.09.25.09.30.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Sep 2020 09:30:30 -0700 (PDT) Subject: Re: [PATCH v2] : Add nitems() and snitems() macros To: Jonathan Wakely Cc: libc-alpha@sourceware.org, libc-coord@lists.openwall.com, libstdc++@gcc.gnu.org, gcc@gcc.gnu.org, linux-kernel@vger.kernel.org, linux-man@vger.kernel.org, fweimer@redhat.com, ville.voutilainen@gmail.com, enh@google.com, rusty@rustcorp.com.au References: <20200922145844.31867-1-colomar.6.4.3@gmail.com> <20200925132000.235033-1-colomar.6.4.3@gmail.com> <20200925144822.GM6061@redhat.com> From: Alejandro Colomar Message-ID: <22c110fe-4c92-e5e6-dc35-dbf00a97cfa2@gmail.com> Date: Fri, 25 Sep 2020 18:30:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200925144822.GM6061@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 16:30:33 -0000 Hello Jonathan, On 2020-09-25 16:48, Jonathan Wakely wrote: > Do you really need to provide snitems? > > Users can use (ptrdiff_t)nitems if needed, can't they? They can, but that adds casts in the code, which makes longer lines that are somewhat harder to read. To avoid that, users may sometimes omit the cast with possible UB. BTW, I use IMO, array indices should be declared as 'ptrdiff_t' always, and not 'size_t'. More generically, I use unsigned integer types for two reasons: bitwise operations, and library functions that require me to do so. I don't intend to force anyone with my opinion, of course, but if I were to choose a type for 'nitems()', it would be 'ptrdiff_t'. However, for legacy reasons people will expect that macro to be unsigned, so I'd have 'nitems()' unsigned, and then a signed version prefixed with an 's'. Some very interesting links about this topic: Bjarne Stroustrup (and others) about signed and unsigned integers: https://www.youtube.com/watch?v=Puio5dly9N8&t=12m56s https://www.youtube.com/watch?v=Puio5dly9N8&t=42m41s The two links above are two interesting moments of the same video. I guess that might be the reason they added std::ssize, BTW. Google's C++ Style Guide about unsigned integers: https://google.github.io/styleguide/cppguide.html#Integer_Types And the most voted StackOverflow answer to the question 'What is the correct type for array indexes in C?': https://stackoverflow.com/a/3174900/6872717 > > C++ provides std::ssize because there are reasons to want it in > generic contexts when using the function on arbitrary container-like > objects. But for an array size you know that ptrdiff_t is wide enough > to represent the size of any array.> > Do you have a use case that requries snitems, or can you assume YAGNI? > I have a few use cases: 1) int alx_gnuplot_set_style (struct Alx_Gnuplot *restrict gnuplot, int style, const char *restrict opt) { if (style < 0 || style >= ARRAY_SSIZE(styles)) return -1; if (alx_strlcpys(gnuplot->style, styles[style], ARRAY_SIZE(gnuplot->style), NULL)) return -1; if (opt) return alx_strbcatf(gnuplot->style, NULL, " %s", opt); return 0; } [https://github.com/alejandro-colomar/libalx/blob/master/src/extra/plot/setup.c] 2) I have many loops that access arrays; I'll just make up an example of how I normally access arrays: void foo(ptrdiff_t nmemb) { int arr[nmemb]; for (ptrdiff_t i = 0; i < ARRAY_SSIZE(arr); i++) arr[i] = i; } Grepping through my code, I have a similar number of ARRAY_SIZE() and ARRAY_SSIZE(). I could have '#define snitems(arr) ((ptrdiff_t)nitems(arr))' in my projects, but is it really necessary? Did I convince you? :-) Thanks, Alex