[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a7f33e89-4815-2210-7627-14757198a666@gmail.com>
Date: Fri, 25 Sep 2020 19:46:04 +0200
From: Alejandro Colomar <colomar.6.4.3@...il.com>
To: Jonathan Wakely <jwakely@...hat.com>
Cc: fweimer@...hat.com, linux-man@...r.kernel.org, libc-alpha@...rceware.org,
gcc@....gnu.org, rusty@...tcorp.com.au, linux-kernel@...r.kernel.org,
libstdc++@....gnu.org, libc-coord@...ts.openwall.com, enh@...gle.com
Subject: Re: [PATCH v2] <sys/param.h>: Add nitems() and snitems() macros
On 2020-09-25 19:39, Jonathan Wakely wrote:
> Yes, I'm aware of all the rationale. I already said that it makes
> sense in C++ where you have generic code. I am not convinced that it's
> necessary to add to <sys/param.h> when all it does is a cast from
> size_t to ptrdiff_t.
>
While I would prefer a signed version, I could live with only
'nitems()'. Having all the __must_be_array thing is the most important
part.
On 2020-09-25 19:42, Jonathan Wakely wrote:
> On 25/09/20 18:30 +0200, Alejandro Colomar via Libstdc++ wrote:
>> 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?
>
> The barrier for adding something to glibc headers should be a LOT
> higher than "I could [do it in my own code], but is it really
> necessary?"
>
>> Did I convince you? :-)
>
> No.
>
>
Well, you convinced me :)
I'll rewrite the patch, and the problem about <stddef.h> will vanish.
Cheers,
Alex
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
