Re: n3752, alx-0029r8 - Restore the traditional realloc(3) specification

Re: n3752, alx-0029r8 - Restore the traditional realloc(3) specification

[Alejandro Colomar]

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

Hi Robert,

On Tue, Jan 06, 2026 at 04:49:18PM -0500, Robert Seacord wrote:
> It's sort of unusual for the committee to pass some sort of statement
> saying we won't change the behavior of something.  Besides your paper,  I
> don't know of any proposals that would affect realloc. Maybe we should hear
> from the UB Study Group as maybe they have some idea to eliminate this UB.

Here are my plans for the next meeting:

A)  Vote the proposal in its entirety.  Ideally, this would pass, which
    would align us with POSIX.

B)  If that doesn't pass, vote the first step (see 'Design decisions'),
    which would be to make realloc(p,s) consistent with free(p) and
    malloc(s), including when p==NULL, and including when size==0.  This
    would be a narrower change that would only affect MS and glibc (and
    compatible implementations).

C)  If that doesn't pass, vote a statement that the committee agrees
    to not remove the UB unless it's for aligning with the traditional
    BSD behavior.

> 
> I think my preference (and I think the consensus of WG14 in Brno) is to
> provide a replacement function with well-defined behavior and deprecate the
> existing function.

Again, this is dead on arrival.

-  The BSDs and musl have a perfect realloc(3), and they won't change
   it.  Programs work well with their realloc(3), so what incentive
   would they have to change the world?

-  POSIX has also already agreed to fix realloc(3), so the above extends
   to all POSIX systems: once realloc(3) is fixed in their systems, what
   would be the incentive to use a new realloc variant that works in the
   same exact way?

Also, the consensus reached in Brno is flawed, as several members told
me they'd change their vote just a few hours later.  They admitted not
having read the proposal prior to the vote, and that after when they
understood the proposal, they agreed with it.

Plus, it was just a non-binding direction poll, so the interpretation is
up to me, and I consider the direction is now to insist, per the quick
change of mind of several committee members, and the recent POSIX
agreement.


Have a lovely night!
Alex

> 
> Thanks,
> rCs
> 
> On Tue, Jan 6, 2026, 4:05 PM Alejandro Colomar <une+c@alejandro-colomar.es>
> wrote:
> 
> > Hi Robert,
> >
> > On Tue, Jan 06, 2026 at 03:12:36PM -0500, Robert Seacord wrote:
> > > I'm still waiting to hear from GCC that they plan to change the behavior
> > of
> > > realloc and break their existing code.
> >
> > realloc(3) is part of glibc, not GCC.
> >
> > From glibc, I can quote Florian Weimer:
> >
> > <
> > https://inbox.sourceware.org/libc-alpha/8734kl1pim.fsf@oldenburg.str.redhat.com/
> > >
> >
> > | I'm open to looking at this again once the C standard fully specifies
> > | the behavior of zero-sized objects, the return value of malloc (0), and
> > | so on.  Getting aligned behavior between implementations on these
> > | fundamental interfaces seems quite valuable to programmers.  But
> > | addressing one zero-object-size case and leaving all the others as
> > | unclear as before doesn't seem to be useful, especially given that a
> > | ffuture standard may require different behavior anyway.  A
> > | piece-by-piece transition to the newly required behaviors is also more
> > | onerous on programmers than one well-defined transition in a single
> > | glibc release.
> >
> > He's CCd, in case he wants to comment further.
> >
> > >  If GCC plans to do this, it could
> > > well change my vote.
> > > Better still, they should just change it now.
> >
> > I agree with you.  But they are worried that the committee might later
> > "require different behavior anyway".  That's why a statement from the
> > committee saying "we agree to not change this UB to something different
> > than the traditional behavior" would be useful.
> >
> > >  It's currently UB so they
> > > can make your proposed changes without breaking compatibility with the
> > > standard.
> >
> > They worry about compatibility to future standards, which is reasonable
> > given how volatile the C Committee has been historically regarding these
> > APIs.
> >
> > > FWIW, the reason we got here is because we didn't want to force compilers
> > > to break their existing code to remain compliant.
> > >
> > > Thanks,
> > > rCs
> >
> > Have a lovely night!
> > Alex
> >
> > --
> > <https://www.alejandro-colomar.es>
> >

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

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

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

[Alejandro Colomar]

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

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>

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

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

[Alejandro Colomar]

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

On Wed, Jan 07, 2026 at 01:38:19PM +0000, David Svoboda wrote:
> Hi, Alex!

Hi David!

> 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).

Agree; UB 182 is already covered by the usual rules for NULL.

I thought you were talking about the UB introduced in C23, but that one
seems not documented in Annex J.  In fact, it's still documented
incorrectly as ID (J.3.13 entry 41, in N3220).

The UB we should be talking about is specified in 7.24.3.7p3:

	[...]  Otherwise, [...], or if the size is zero, the
	behavior is undefined.


Have a lovely night!
Alex

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

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

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

[Joseph Myers]

On Wed, 7 Jan 2026, Alejandro Colomar wrote:

> I thought you were talking about the UB introduced in C23, but that one
> seems not documented in Annex J.  In fact, it's still documented
> incorrectly as ID (J.3.13 entry 41, in N3220).

See 
https://stackoverflow.com/questions/78691087/reallocptr-0-in-c23-now-what 
regarding the lists of UB related to realloc being out of date.  I think 
this could be fixed editorially via a merge request (to make the Annex J 
lists in C2y agree with the actual current realloc semantics in C2y) but I 
haven't got round to writing such an MR myself.

-- 
Joseph S. Myers
josmyers@redhat.com

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

[Martin Uecker]

Am Mittwoch, dem 07.01.2026 um 22:01 +0000 schrieb Joseph Myers:
> On Wed, 7 Jan 2026, Alejandro Colomar wrote:
> 
> > I thought you were talking about the UB introduced in C23, but that one
> > seems not documented in Annex J.  In fact, it's still documented
> > incorrectly as ID (J.3.13 entry 41, in N3220).
> 
> See 
> https://stackoverflow.com/questions/78691087/reallocptr-0-in-c23-now-what 
> regarding the lists of UB related to realloc being out of date.  I think 
> this could be fixed editorially via a merge request (to make the Annex J 
> lists in C2y agree with the actual current realloc semantics in C2y) but I 
> haven't got round to writing such an MR myself.


There know of various other issues and omissions in Annex J3.  I think
it would be good if the UB study group informally takes over maintenance
of this annex. 

Martin

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

[Joseph Myers]

On Thu, 8 Jan 2026, David Svoboda wrote:

> I would agree.  I interpret "informally take over" to mean two things:
> 
> 1. I would like someone to volunteer to scan the C2y draft standard 
> (n3605) specifically to catch errors in Annex J.2.  In particular, are 
> there any UBs in J2 no longer in the standard. Likewise does the 
> standard have any UBs not in J.2?  The result would be a document 
> recommending editorial changes to Annex J.2.

It's probably not just J.2.  My guess is that J.1 (Unspecified behavior), 
J.3 (Implmentation-defined behavior) and J.4 (Locale-specific behavior) 
could all also be out of date relative to the normative contents of the 
standard.

In the case of checking for UBs, it needs to include "shall" or "shall 
not" outside constraints, whose violation is UB and ought to be listed as 
such in J.2 (when it's not a ghost - so when that "shall" or "shall not" 
expresses a requirement on C programs, not on implementations, that it is 
possible to violate without also violating a syntax rule or constraint), 
as well as places that explicitly say "undefined" in normative text.  
Also, some entries in J.2 may be things that are implicitly UB through 
lack of definition (so the absence of something in the normative text 
saying "undefined", "shall" or "shall not" isn't enough basis to remove 
something from J.2 editorially, you also need to locate the change that 
removed the UB from the normative text to demonstrate that there was an 
accidental failure to remove an entry from J.2).

Trickier cases where it's less clear why the entry was in J.2 in the first 
place, or where you need to argue that the entry is in fact a ghost, 
should still get papers.  It's the ones that can be identified as 
accidental omissions to update Annex J (in either direction) when a change 
was made to the normative text that I think can be made editorially by 
merge requests without papers (and then if someone is concerned with such 
a change afterwards, they can request a revert and a paper to discuss it 
further).

I've wondered if it would be better to set up the LaTeX source of the 
standard so that the Annex J entries appear in the sources alongside the 
relevant parts of the normative text and get automatically collected for 
Annex J, rather than appearing separately in annex-port.tex, but that 
would be a big change and a lot of care would be needed not to lose any 
Annex J entries in the process.

-- 
Joseph S. Myers
josmyers@redhat.com

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

[Florian Weimer]

* David Svoboda:

> 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.

If glibc makes the change, it becomes the problem of our users (and
developers who interpose glibc's malloc).  I'm not sure that's a helpful
approach.  Someone needs to take responsibility.

For glibc, we would have to do some analysis to figure out the impact.
I don't think the glibc team at Red Hat will be able to work on this in
the foreseeable future.  I don't we should make such changes upstream
without such an analysis.

What's Microsoft's position on this entire topic?  I thought they use
the glibc behavior, too?

Thanks,
Florian

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

[Alejandro Colomar]

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

Hi Florian, David,

On Wed, Jan 07, 2026 at 06:30:47PM +0100, Florian Weimer wrote:
> * David Svoboda:
> 
> > 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.

A major implementation, gnulib, has done the switch in 2024 after this
proposal.  No regressions are known.  We would have certainly noticed
if something important had happened.

> If glibc makes the change, it becomes the problem of our users (and
> developers who interpose glibc's malloc).  I'm not sure that's a helpful
> approach.

A reminder: glibc's realloc(p,0) already can return non-null
(if p==NULL before the call).  This means that correct glibc code must
be able to handle the possibility of realloc(p,0) returning a non-null
pointer.

> Someone needs to take responsibility.

What do you mean exactly by this?

> For glibc, we would have to do some analysis to figure out the impact.

I have done some theoretical analysis in the paper.

gnulib has done some experimental analysis, to the extent that it has
done the change in 2024, and we're already in 2026 and we've seen zero
regression reports so far.  This is used in GNU coreutils, which is
certainly something essential enough that if it had any important
issues, we would have noticed by now.

You could do some more, but with the resources we have, this should be
quite convincing.

> I don't think the glibc team at Red Hat will be able to work on this in
> the foreseeable future.  I don't we should make such changes upstream
> without such an analysis.
> 
> What's Microsoft's position on this entire topic?  I thought they use
> the glibc behavior, too?

Microsoft doesn't seem to have representation in the committee.  At
least, they haven't showed up to talk about this.


Cheers,
Alex

> 
> Thanks,
> Florian
> 

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

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

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

[Florian Weimer]

* Alejandro Colomar:

> Hi Florian, David,
>
> On Wed, Jan 07, 2026 at 06:30:47PM +0100, Florian Weimer wrote:
>> * David Svoboda:
>> 
>> > 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.
>
> A major implementation, gnulib, has done the switch in 2024 after this
> proposal.  No regressions are known.  We would have certainly noticed
> if something important had happened.

gnulib is a sub-settable copylib, so it only affects gnulib-using
applications that end up copying the relevant realloc implementation
from gnulib (there are at least two).  This is a relatively small set of
applications, and they typically run only for a limited time.

It's not that users update systems to a newer gnulib and applications
switch to a different realloc implementation.  It's a very incremental
roll-out.

>> Someone needs to take responsibility.
>
> What do you mean exactly by this?

It was suggested that WG14 can just make the change and ignore its
consequences for glibc and other implementations.  For glibc, we could
also make the change and tell our users to deal with the breakage.  I
don't think this is a good approach.

> You could do some more, but with the resources we have, this should be
> quite convincing.

I don't feel comfortable changing glibc based on the data we have so
far.

Thanks,
Florian

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

[Adhemerval Zanella Netto]

On 08/01/26 08:18, Florian Weimer wrote:
> * Alejandro Colomar:
> 
>> Hi Florian, David,
>>
>> On Wed, Jan 07, 2026 at 06:30:47PM +0100, Florian Weimer wrote:
>>> * David Svoboda:
>>>
>>>> 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.
>>
>> A major implementation, gnulib, has done the switch in 2024 after this
>> proposal.  No regressions are known.  We would have certainly noticed
>> if something important had happened.
> 
> gnulib is a sub-settable copylib, so it only affects gnulib-using
> applications that end up copying the relevant realloc implementation
> from gnulib (there are at least two).  This is a relatively small set of
> applications, and they typically run only for a limited time.
> 
> It's not that users update systems to a newer gnulib and applications
> switch to a different realloc implementation.  It's a very incremental
> roll-out.
> 
>>> Someone needs to take responsibility.
>>
>> What do you mean exactly by this?
> 
> It was suggested that WG14 can just make the change and ignore its
> consequences for glibc and other implementations.  For glibc, we could
> also make the change and tell our users to deal with the breakage.  I
> don't think this is a good approach.
> 
>> You could do some more, but with the resources we have, this should be
>> quite convincing.
> 
> I don't feel comfortable changing glibc based on the data we have so
> far.

I tend to agree, we may try to change using compat symbols but it would
add extra complications on malloc interposes.  

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

[Alejandro Colomar]

[-- 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 --]

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

[Alejandro Colomar]

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

Hi Nevin,

On Wed, Jan 07, 2026 at 08:37:15PM -0600, Nevin Liber wrote:
> On Wed, Jan 7, 2026 at 8:31 AM David Svoboda <svoboda@cert.org> wrote:
> 
> > Here are some more thoughts on n3752
> > [...]
> > 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?
> >
> 
> And if it breaks no code, is that because this is a corner case that
> doesn't occur in practice?

It's not because of a corner case.  It's because if it would go wrong,
the worst that can happen is a memory leak of 0 bytes plus metadata
(~16 B, usually).

And yes, it's a corner case, so it's not like you'll be leaking those
16 B regularly.

> That in itself doesn't mean we shouldn't change it.

The reason to change it is that with the current specification and
implementation you can get serious vulnerabilities: remote code
execution.

Also, that programming will be much easier if all implementations behave
in the most simple way.

> > 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.
> >
> 
> This is the part that is troublesome to me.  What is the point of changing
> this behavior if two (or even just one) major implementations are going to
> ignore it?

Do you know anyone from MS in WG21?  It would be great to talk to them.


Have a lovely day!
Alex

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

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

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

[Alejandro Colomar]

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

Hi Nevin,

On Tue, Jan 06, 2026 at 04:16:11PM -0600, Nevin Liber wrote:
> On Tue, Jan 6, 2026 at 3:05 PM Alejandro Colomar <une+c@alejandro-colomar.es>
> wrote:
> 
> > I agree with you.  But they are worried that the committee might later
> > "require different behavior anyway".  That's why a statement from the
> > committee saying "we agree to not change this UB to something different
> > than the traditional behavior" would be useful.
> >
> 
> We cannot put requirements like this on future committees, nor is there
> anyone who can speak on behalf of future committees.

Agree.

Which is why the only solution is to actually fix the standard
definition of realloc(3).  And is also why POSIX will fork realloc(3)
regardless of what ISO C says about it: currently, POSIX would be still
compatible, because UB can be defined, but in the future, if ISO C
deviates, the POSIX realloc(3) will be effectively a fork, and ISO C
will be ignored.

If ISO C doesn't want to be forked, it only has an option: follow POSIX.

> We can, of course, talk about the likelihood of this behavior changing
> again, strengthened by vote counts.

Yup.


Have a lovely night!
Alex

> -- 
>  Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>>
> +1-847-691-1404

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

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

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

[Alejandro Colomar]

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

Hi Philipp,

On Wed, Jan 07, 2026 at 02:55:03PM +0100, Philipp Klaus Krause wrote:
> Am 06.01.26 um 21:12 schrieb Robert Seacord:
> > I'm still waiting to hear from GCC that they plan to change the behavior
> > of realloc and break their existing code.  If GCC plans to do this, it
> > could well change my vote.
> 
> Not GCC here.
> 
> SDCC changed its malloc/realloc aligning it with Alejandro's proposal a few
> months ago, and the new behaviour will be in the next release (SDCC 4.6.0).
> 
> We made this decision after discussion among SDCC developers and users, and
> think that this is the best solution for SDCC and its users. We are not
> making any statement about this solution being appropriate for the standard
> or other implementations.

Wow!  Thanks!  That makes it two implementations that have already
changed to adapt to this behavior after the proposal:

	-  SDCC (SDCC 4.6.0)
	-  gnulib (2024-11)

Plus of course the POSIX standard itself.  That's looking good.


Have a lovely night!
Alex

> 
> Philipp
> 

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

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