[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV6_UHBxHrOsL3qD@devuan>
Date: Wed, 7 Jan 2026 21:28:30 +0100
From: Alejandro Colomar <une+c@...jandro-colomar.es>
To: Florian Weimer <fweimer@...hat.com>
Cc: David Svoboda <svoboda@...t.org>, Robert Seacord <rcseacord@...il.com>,
"sc22wg14@...n-std. org" <sc22wg14@...n-std.org>, 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.34664] n3752, alx-0029r8 - Restore the traditional
realloc(3) specification
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>
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.
