Hi Paul, On Sat, Oct 19, 2024 at 11:08:13AM -0700, Paul Eggert wrote: > On 2024-10-19 01:25, Bruno Haible wrote: > > > If not, can you please summarize the conclusions? > > I think Alejandro has done that now. > > > > it would be premature to change lib/realloc.c, _before_ glibc has > > made any change. > > Yes, we're working on the glibc side. (It's a little question of scheduling. > :-) > > > > That's not what Gnulib is made for: causing additional work for the > > developer. > > The goal is to make the change as painless as possible. I agree that there > may be some additional work, for developers who want to avoid all memory > leaks no matter how small, and whose packages unwisely are relying on the > current glibc semantics. However, packages like this are rare and the harm > (if the work isn't done) small.
I don't remember what we've changed and what we still need to change. Could you please remind me of what gnulib has done regarding realloc(p, 0)? Is there anything else we need to do, or gnulib is done? Should we start looking at glibc? The C Committee is talking about realloc(p, 0), and I'd like to update them about the situation in GNU land. Thanks! Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
