[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PH1P110MB163601133BF0167C46C8CC9DCC84A@PH1P110MB1636.NAMP110.PROD.OUTLOOK.COM>
Date: Wed, 7 Jan 2026 14:31:31 +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
Here are some more thoughts on n3752
I wish the paper said something in the intro along the lines of "the goal to change realloc(0) to return a non-null value upon success". That is implicit in the paper, but should be explicit.
Alex, I recommend that when presenting this paper, please explain carefully the edge cases of how realloc() currently works in C23. This is because some of us know how it works in C17, some of us remember DR 400, some only know C99's behavior, and some only know C89's. So your audience is fragmented, and think they know how it works (without knowing the edge cases like realloc(0)).
WRT this text:
Code written for platforms returning a null pointer can be
migrated to platforms returning non-null, without significant
issues.
I am very skeptical that this is indeed true. But to be precise, this is Glibc's problem rather than WG14's. If they are willing to change glibc to return non-null on realloc(0), then I am willing to agree to this change in ISO C.
Is there any evidence that changing this behavior breaks no code? Any test failures? Any surveys?
This paper ignores Windows other than to mention that it would need to change too. I doubt MS will update MSVC to accommodate this paper. So accepting this paper makes MSVC noncompliant.
--
David Svoboda svoboda@....cmu.edu<mailto:svoboda@....cmu.edu>
Senior Software Security Engineer
CERT Applied Systems Group
(412) 596-0401
From: David Svoboda <svoboda@...t.org>
Date: Wednesday, January 7, 2026 at 8:38 AM
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.
