[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZoq6rRerpgmKbJHcEHCwPjOTBO3FRxk+DsS-6yp=_ja00A@mail.gmail.com>
Date: Mon, 16 Jun 2025 12:40:18 -0400
From: enh <enh@...gle.com>
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,
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 7:55 AM Alejandro Colomar <alx@...nel.org> 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.
android has these tests in the compatibility test suite (cts):
TEST(malloc, realloc_nullptr_0) {
// realloc(nullptr, size) is actually malloc(size).
void* p = realloc(nullptr, 0);
ASSERT_TRUE(p != nullptr);
free(p);
}
TEST(malloc, realloc_0) {
void* p = malloc(1024);
ASSERT_TRUE(p != nullptr);
// realloc(p, 0) is actually free(p).
void* p2 = realloc(p, 0);
ASSERT_TRUE(p2 == nullptr);
}
> - 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.
>
> 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?
>
> 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.
>
>
> Have a lovely day!
> Alex
>
> --
> <https://www.alejandro-colomar.es/>
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.
