[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV4N-0egpfxhmnta@devuan>
Date: Wed, 7 Jan 2026 08:51:41 +0100
From: Alejandro Colomar <une+c@...jandro-colomar.es>
To: David Svoboda <svoboda@...t.org>
Cc: Robert Seacord <rcseacord@...il.com>,
"sc22wg14@...n-std. org" <sc22wg14@...n-std.org>, Florian Weimer <fweimer@...hat.com>,
Carlos O'Donell <carlos@...hat.com>, Aaron Ballman <aaron@...onballman.com>,
libc-alpha@...rceware.org, musl@...ts.openwall.com, linux-man@...r.kernel.org
Subject: Re: [SC22WG14.34664] n3752, alx-0029r8 - Restore the traditional
realloc(3) specification
Hi David,
On Wed, Jan 07, 2026 at 12:47:18AM +0000, David Svoboda wrote:
[...]
> I could argue that this UB is really redundant, as it is a variant of
> the UB you get from reading past the end of an array.
> (notwithstanding that the array has zero length).
Clearly not. First of all, requesting an array of zero elements is not
accessing the array, so you can't put both UB in the same category.
Second, NULL is not an array of zero elements. NULL is an invalid
pointer. You can't do anything with NULL (or you couldn't until it was
changed recently). With an array of zero elements, you can do pointer
arithmetic and hold the pointer just fine, as long as you don't read
past the end:
int a[0];
int *p, *end;
p = a;
end = a + _Countof(a);
while (p < end)
do_stuff(p);
The above is valid in compilers that support arrays of zero elements,
but is (was) not valid with NULL.
And third, a pointer to the first element of an array of zero elements
is *not* past the end; it is the same as a pointer one after the last
element, and thus it's perfectly valid to hold it.
> We could also argue that this should be implementation-defined
> behavior, or even unspecified behavior.
No, this is what we had in C17, and UB is much better than that.
C17 destroyed the standard definition of realloc(p,0), even though it
was supposed to be a no-op change. To some degree, I'm happy that that
changed, as that brought us to now, where it is obvious that the only
way forward is to go back to the traditional BSD specification.
> However, the UBSG's current
> arsenal for slaying earthly demons has traditionally not extended to
> changing what platforms do, as n3752 does. So IMO the UBSG should
> stand back and wait for n3752 to be resolved.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
