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

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

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