[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250616122411.GW1827@brightrain.aerifal.cx>
Date: Mon, 16 Jun 2025 08:24:15 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: libc-alpha@...rceware.org,
наб <nabijaczleweli@...ijaczleweli.xyz>,
Paul Eggert <eggert@...ucla.edu>,
Robert Seacord <rcseacord@...il.com>, musl@...ts.openwall.com,
Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
bug-gnulib@....org, JeanHeyd Meneide <phdofthehouse@...il.com>
Subject: Re: BUG: realloc(p,0) should be consistent with malloc(0)
On Mon, Jun 16, 2025 at 01:55:26PM +0200, Alejandro Colomar wrote:
> Hi!
>
> For context, the old discussion was in this thread:
> <https://inbox.sourceware.org/libc-alpha/nbyurzcgzgd5rdybbi4no2kw5grrc32k63svf7oq73nfcbus5r@77gry66kpqfr/>
>
> Also for context, here's the excellent research by наб about malloc(0)
> and realloc(p, 0) in historic UNIX systems and their descendents:
> <https://nabijaczleweli.xyz/content/blogn_t/017-malloc0.html>
>
> We discussed last year about realloc(p, 0) being problematic currently
> in glibc. Ideally, realloc(p, n) should be consistent with malloc(n)
> in that:
>
> - It is equivalent to free(p) and malloc(n), regardless of the value of
> n, including when it is 0, and regardless of p, including when it is
> NULL.
>
> - Except that of course, if there's enough contiguous space, it doesn't
> free/malloc, and taht if malloc(n) fails, it doesn't free(p).
>
> This congruency existed in every UNIX system and their descendents,
> including the historic BSDs. It wasn't until new systems were written
> artificially by the letter of the standard, without regards to
> self-consistency, when this congruency was broken. I believe glibc was
> the first one to do that, and I don't know/remember if any other systems
> followed glibc.
>
> Paul Eggert and I are convinced that changing the implementation to
> conform to this behavior consistent with malloc(0) would be harmless.
> As such, we modified gnulib's realloc-posix module to conform to that.
> 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.
> 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.
> 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.
Rich
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.
