From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 15C5C3971C14 for ; Fri, 25 Sep 2020 14:48:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 15C5C3971C14 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-512-lVpsl2L7PmSm51S3Uh_5sw-1; Fri, 25 Sep 2020 10:48:29 -0400 X-MC-Unique: lVpsl2L7PmSm51S3Uh_5sw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7F9EB80B70F; Fri, 25 Sep 2020 14:48:24 +0000 (UTC) Received: from localhost (unknown [10.33.36.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 870735C1BB; Fri, 25 Sep 2020 14:48:23 +0000 (UTC) Date: Fri, 25 Sep 2020 15:48:22 +0100 From: Jonathan Wakely To: Alejandro Colomar 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 Subject: Re: [PATCH v2] : Add nitems() and snitems() macros Message-ID: <20200925144822.GM6061@redhat.com> References: <20200922145844.31867-1-colomar.6.4.3@gmail.com> <20200925132000.235033-1-colomar.6.4.3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable 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 14:48:35 -0000 On 25/09/20 16:10 +0200, Alejandro Colomar wrote: > > >On 2020-09-25 15:20, Alejandro Colomar wrote: >> 'nitems()' calculates the length of an array in number of items. >> It is safe: if a pointer is passed to the macro (or function, in C++), >> the compilation is broken due to: >> - In >= C11: _Static_assert() >> - In C89, C99: Negative anonymous bitfield >> - In C++: The template requires an array >> >> 'snitems()' is equivalent to nitems(), >> but it returns a 'ptrdiff_t' instead of a 'size_t'. >> It is useful for comparison with signed integer values. >> >> Some BSDs already provide a macro nitems() in , >> although it usually doesn't provide safety against pointers. >> >> This patch uses the same name for compatibility reasons, >> and to be the least disruptive with existing code. >> >> This patch also adds some other macros, which are required by 'nitems()': >> >> __is_same_type(_A, _B): >> Returns non-zero if the two input arguments are of the same type. >> >> __is_array(_Arr): >> Returns non-zero if the input argument is of an array type. >> >> __must_be(_Expr, _Msg): >> Allows using _Static_assert() everywhere an expression can be used. >> It evaluates '(int)0' or breaks the compilation. >> >> __must_be_array(_Arr): >> It evaluates to '(int)0' if the argument is of an array type. >> Else, it breaks compilation. >> >> __array_len(_Arr): >> It implements the basic sizeof division needed to calculate the >array length. >> >> >> P.S.: I'd like to put this patch in the public domain. >> >> >> Signed-off-by: Alejandro Colomar >> --- > >I patched my own system's with this, >and while 'nitems()' works fine, >I had to include in my main.c to be able to use 'snitems()', >because I didn't have 'ptrdiff_t', >eventhough already includes . > >I completely ignore the mechanisms behind system headers including >other system headers. > >Moreover, I didn't find 'ptrdiff_t' defined in any of my systems headers >I used 'user@debian:/usr/include$ grep -rn ptrdiff_t'. Does GCC do magic? > >What's the problem with that? How should I fix the patch? Do you really need to provide snitems? Users can use (ptrdiff_t)nitems if needed, can't they? 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?