[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8n4Xf1uvcNCvycvrn4SvjWN2ttXFW6-75tyEbtUO916MQ@mail.gmail.com>
Date: Tue, 24 Jun 2025 20:14:32 -0400
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Cc: Florian Weimer <fweimer@...hat.com>, libc-alpha@...rceware.org, bug-gnulib@....org,
наб <nabijaczleweli@...ijaczleweli.xyz>,
Douglas McIlroy <douglas.mcilroy@...tmouth.edu>, Paul Eggert <eggert@...ucla.edu>,
Robert Seacord <rcseacord@...il.com>, Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
JeanHeyd Meneide <phdofthehouse@...il.com>, Rich Felker <dalias@...c.org>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>, Joseph Myers <josmyers@...hat.com>,
Laurent Bercot <ska-dietlibc@...rnet.org>, Andreas Schwab <schwab@...e.de>,
Eric Blake <eblake@...hat.com>, Vincent Lefevre <vincent@...c17.net>, Mark Harris <mark.hsj@...il.com>,
Collin Funk <collin.funk1@...il.com>, Wilco Dijkstra <Wilco.Dijkstra@....com>,
DJ Delorie <dj@...hat.com>, Cristian Rodríguez <cristian@...riguez.im>,
Siddhesh Poyarekar <siddhesh@...plt.org>, Sam James <sam@...too.org>, Mark Wielaard <mark@...mp.org>,
"Maciej W. Rozycki" <macro@...hat.com>, Martin Uecker <ma.uecker@...il.com>,
Christopher Bazley <chris.bazley.wg14@...il.com>, eskil@...ession.se,
Daniel Krügler <daniel.kruegler@...glemail.com>,
Kees Cook <keescook@...omium.org>, Valdis Klētnieks <valdis.kletnieks@...edu>
Subject: Re: Re: alx-0029r3 - Restore the traditional realloc(3) specification
On Tue, Jun 24, 2025 at 10:18 AM Alejandro Colomar <alx@...nel.org> wrote:
>
> Hi Florian,
>
> On Tue, Jun 24, 2025 at 11:07:53AM +0200, Florian Weimer wrote:
> > [...]
> > Wouldn't it be more consistent to move in the other direction, and
> > require that allocations of zero size fail because C does not support
> > zero-sized objects?
>
> That's what some people have attempted since the times of SysV and C89.
> Three decades after, people haven't achieved that, and we see the
> fallout.
>
> Plus, the only direction in which moving is relatively safe is from
> returning-NULL behavior to returning-non-null behavior. Consider this
> code written for a realloc(p,0) that returns NULL:
>
> errno = 0;
> new = realloc(old, n);
> if (new == NULL) {
> if (errno == ENOMEM)
> free(old);
> goto fail;
> }
> ...
> free(new);
>
> If you suddenly return non-null from realloc(p,0), that code will
> continue behaving well. In some other cases, as you can see in my
> proposal, a memory leak would be introduced, which is a very mild
> problem.
I don't think a small memory leak is always a mild problem. On
Android, it could [eventually] use up all device memory as shared
objects are unloaded/loaded during the lifetime of an activity. I know
OpenSSL used to give the Java folks a lot of problems because they
(OpenSSL) was not cleaning up memory during the unload.
Jeff
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.
