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/>
signature.asc
Description: PGP signature