[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lhuqzs1uy7s.fsf@oldenburg.str.redhat.com>
Date: Wed, 07 Jan 2026 18:30:47 +0100
From: Florian Weimer <fweimer@...hat.com>
To: David Svoboda <svoboda@...t.org>
Cc: Alejandro Colomar <une+c@...jandro-colomar.es>, 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>
Subject: Re: [SC22WG14.34664] n3752, alx-0029r8 - Restore the traditional
realloc(3) specification
* 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
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.
