[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7327a6c0-3102-441b-b689-4ecf068a5bbc@linaro.org>
Date: Thu, 8 Jan 2026 08:53:23 -0300
From: Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>
To: musl@...ts.openwall.com, Florian Weimer <fweimer@...hat.com>,
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>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
Paul Eggert <eggert@...ucla.edu>
Subject: Re: Re: [SC22WG14.34664] n3752, alx-0029r8 - Restore the
traditional realloc(3) specification
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.
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.
