[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lhuldi8pd2p.fsf@oldenburg.str.redhat.com>
Date: Thu, 08 Jan 2026 12:18:38 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Alejandro Colomar <une+c@...jandro-colomar.es>
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
* 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
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.
