[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dxtllgfgt367vmwjby4nxliaetnd7t4o6jxev23qx4mwkadoyi@pwhw3skkmhei>
Date: Mon, 16 Jun 2025 14:43:11 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Rich Felker <dalias@...c.org>, Paul Eggert <eggert@...ucla.edu>,
Bruno Haible <bruno@...sp.org>
Cc: libc-alpha@...rceware.org,
наб <nabijaczleweli@...ijaczleweli.xyz>, Robert Seacord <rcseacord@...il.com>, musl@...ts.openwall.com,
Elliott Hughes <enh@...gle.com>, bug-gnulib@....org, JeanHeyd Meneide <phdofthehouse@...il.com>
Subject: Re: BUG: realloc(p,0) should be consistent with malloc(0)
Hi Rich, Paul, Bruno,
On Mon, Jun 16, 2025 at 08:24:15AM -0400, Rich Felker wrote:
> > This was done in
> >
> > d884e6fc4a60 (2024-11-03, 2024-11-04; "realloc-posix: realloc (..., 0) now returns nonnull")
> >
> > After more than half a year of changing the behavior in gnulib, there
> > have been no dramatic consequences. As expected, no fallout at all.
>
> Do you have numbers for how many packages have actually pulled in the
> updated gnulib and shipped with it? With this change, do you have it
> replacing realloc on glibc, so that the new realloc actually gets
> used? I would expect yes; I'm just asking so that this can be a more
> clear sign to would-be detractors that nothing breaks.
Maybe Paul or Bruno can answer this. I don't know.
> > Now, can we please make the same change in glibc?
> >
> > I've CCed musl and Elliott (Bionic), because I don't remember what's the
> > behavior in their libraries. Is it already self-consistent in musl and
> > Bionic? Or do they need a similar fix?
>
> It's always been self-consistent in musl. realloc(p,0) returns
> non-null except of course on failure (such extreme OOM that allocation
> of 0 bytes is not possible), in which case it behaves like any other
> failure. Note that such failure is possible because our allocator
> segregates allocations by size classes, and it might be impossible to
> make a new slab of smallest-size slots even if a much larger slot
> would be freed.
Thanks!
> > glibc (and possibly libraries that attempt glibc compatibility) is the
> > only libc implementation that is not self consistent, and by which ISO C
> > has UB in realloc(p, 0). We expect that when glibc is fixed,
> > realloc(p, 0) can be allowed again in ISO C, and can be specified to be
> > consistent with malloc(0), thus removing a case of UB.
>
> This would be excellent.
Yep; I want to fix this eventually. (And also mandate that malloc(0)
returns non-null, but that's another story.)
Have a lovely day!
Alex
--
<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.
