[musl] BUG: realloc(p,0) should be consistent with malloc(0)

[Alejandro Colomar]

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/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250616/02f1e1a0/attachment.sig>