All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Alejandro Colomar <colomar.6.4.3@gmail.com>
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] <sys/param.h>: Add nitems() and snitems() macros
Date: Fri, 25 Sep 2020 15:48:22 +0100	[thread overview]
Message-ID: <20200925144822.GM6061@redhat.com> (raw)
In-Reply-To: <f6257d7d-1cea-b45c-a858-b80bbc1f18b1@gmail.com>

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 <sys/param.h>,
>> 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 <colomar.6.4.3@gmail.com>
>> ---
>
>I patched my own system's <sys/param.h> with this,
>and while 'nitems()' works fine,
>I had to include <stddef.h> in my main.c to be able to use 'snitems()',
>because I didn't have 'ptrdiff_t',
>eventhough <sys/param.h> already includes <stddef.h>.
>
>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?


  reply	other threads:[~2020-09-25 14:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87zh5ixcn9.fsf@oldenburg2.str.redhat.com>
2020-09-22 14:58 ` [RFC] <sys/param.h>: Add nitems() and snitems() macros Alejandro Colomar
2020-09-25 13:20   ` [PATCH v2] " Alejandro Colomar
2020-09-25 14:10     ` Alejandro Colomar
2020-09-25 14:48       ` Jonathan Wakely [this message]
2020-09-25 16:30         ` Alejandro Colomar
2020-09-25 17:39           ` Jonathan Wakely
2020-09-25 17:42           ` Jonathan Wakely
2020-09-25 17:46             ` Alejandro Colomar
2020-09-25 19:37               ` [PATCH v3] <sys/param.h>: Add nitems() Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200925144822.GM6061@redhat.com \
    --to=jwakely@redhat.com \
    --cc=colomar.6.4.3@gmail.com \
    --cc=enh@google.com \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-coord@lists.openwall.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=ville.voutilainen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.