[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV7CC9Sr_Wn3dbAB@devuan>
Date: Wed, 7 Jan 2026 21:36:05 +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" <libc-alpha@...rceware.org>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>, Paul Eggert <eggert@...ucla.edu>
Subject: Re: [SC22WG14.34672] n3752, alx-0029r8 - Restore the traditional
realloc(3) specification
Hi David,
On Wed, Jan 07, 2026 at 02:31:31PM +0000, David Svoboda wrote:
> 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".
Agree; that could be said more explicitly. If I need to write another
revision, I'll try to remember to include that.
> 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.
In C23, it doesn't work at all; that's the point. :-)
> 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.
The wording in all those standards is so inconsistent, that I doubt
there's a unique interpretation, and thus I doubt most people know how
it worked in those standards.
I think the only appropriate description of realloc(p,0) is that it was
never correctly specified in the standard, and what matters is what
implementations did in the real world.
> So your audience is fragmented, and think they know how it works
> (without knowing the edge cases like realloc(0)).
They should really read the paper.
> 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.
gnulib has done the change in 2024. No regressions have been reported.
It is a major implementation, used in Linux systems by essential
programs, and in POSIX systems also by many programs.
> 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?
There is gnulib having changed its behavior after this paper. No
problems have been reported.
> 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.
I have no ways of contacting MS. If anyone knows MS people from WG21
that would be relevant, please bring them into the discussion.
Cheers,
Alex
>
>
> --
>
> 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
--
<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.
