Re: [SC22WG14.34672] n3752, alx-0029r8 - Restore the traditional realloc(3) specification

[Alejandro Colomar <une+c@alejandro-colomar.es>]

[-- Attachment #1: Type: text/plain, Size: 6742 bytes --]

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@sei.cmu.edu<mailto:svoboda@sei.cmu.edu>
> 
> Senior Software Security Engineer
> 
> CERT Applied Systems Group
> 
> (412) 596-0401
> 
> From: David Svoboda <svoboda@cert.org>
> Date: Wednesday, January 7, 2026 at 8:38 AM
> To: Alejandro Colomar <une+c@alejandro-colomar.es>
> Cc: Robert Seacord <rcseacord@gmail.com>, sc22wg14@open-std. org <sc22wg14@open-std.org>, Florian Weimer <fweimer@redhat.com>, Carlos O'Donell <carlos@redhat.com>, Aaron Ballman <aaron@aaronballman.com>, libc-alpha@sourceware.org <libc-alpha@sourceware.org>, musl@lists.openwall.com <musl@lists.openwall.com>, linux-man@vger.kernel.org <linux-man@vger.kernel.org>, David Svoboda <svoboda@cert.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@alejandro-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@sei.cmu.edu<mailto:svoboda@sei.cmu.edu>
> 
> Senior Software Security Engineer
> 
> CERT Applied Systems Group
> 
> (412) 596-0401

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]