[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PH1P110MB1636D74EDD4F3074AC98F12FCC84A@PH1P110MB1636.NAMP110.PROD.OUTLOOK.COM>
Date: Wed, 7 Jan 2026 13:38:19 +0000
From: David Svoboda <svoboda@...t.org>
To: Alejandro Colomar <une+c@...jandro-colomar.es>
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" <libc-alpha@...rceware.org>,
"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>, David Svoboda
<svoboda@...t.org>
Subject: Re: [SC22WG14.34664] n3752, alx-0029r8 - Restore the traditional
realloc(3) specification
Hi, Alex!
I'm just going to respond to your first point (about what precisely the UB is):
The n3605 Annex J text says:
(157) A non-null pointer returned by a call to the calloc, malloc, realloc, or aligned_alloc
function with a zero requested size is used to access an object (7.25.4).
This suggests that working with a non-null pointer that has been returned from realloc() is the UB, not invoking realloc(0).
But 7.25.4.8 (realloc) text says:
Otherwise, if ptr does not match a pointer earlier returned by a memory management function, or
if the space has been deallocated by a call to the free or realloc function, or if the size is zero, the
behavior is undefined.
So you're right...UB comes from actually invoking realloc(), not working with whatever it returned. The Annex J wording needs some cleanup. Unless your paper gets accepted, in which case this Annex J UB goes away (and it wouldn't hurt to mention this in your paper, as we have found lots of obsolete UBs in Annex J).
On 1/7/26, 3:43 AM, "Alejandro Colomar" <une+c@...jandro-colomar.es> wrote:
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>
--
David Svoboda svoboda@....cmu.edu<mailto:svoboda@....cmu.edu>
Senior Software Security Engineer
CERT Applied Systems Group
(412) 596-0401
Content of type "text/html" skipped
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.
