[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b2720cc4-58c3-4df1-baa7-c107d0b9d912@cs.ucla.edu>
Date: Mon, 16 Jun 2025 10:35:07 -0700
From: Paul Eggert <eggert@...ucla.edu>
To: Rich Felker <dalias@...c.org>
Cc: libc-alpha@...rceware.org, наб
<nabijaczleweli@...ijaczleweli.xyz>, 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>,
Alejandro Colomar <alx@...nel.org>
Subject: Re: BUG: realloc(p,0) should be consistent with malloc(0)
On 2025-06-16 05:24, Rich Felker wrote:
> 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 don't have numbers, but I've helped to release new GNU coreutils,
diffutils, grep, and gzip with the new Gnulib. No realloc-related
problems have been reported. I expect other GNU apps have also been
released with the new Gnulib.
The new Gnulib replaces all app calls to realloc on platforms like glibc
where realloc does not have the desired behavior. It does not replace
realloc calls within libraries that are linked to.
Since these GNU apps are designed to be portable to musl etc. I would
not have expected the new Gnulib behavior to change observable app
behavior. The Gnulib change is mostly there to mask out any (unlikely)
bugs that would occur if a GNU app incorrectly assumed the current Glibc
realloc behavior (which is obviously bogus).
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.
