[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250625001927.GP1827@brightrain.aerifal.cx>
Date: Tue, 24 Jun 2025 20:19:27 -0400
From: Rich Felker <dalias@...c.org>
To: Jeffrey Walton <noloader@...il.com>
Cc: musl@...ts.openwall.com, 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>,
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 08:14:32PM -0400, Jeffrey Walton wrote:
> 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.
Isn't it normal/expected that Android apps leak memory all over the
place, in significant amounts not malloc(0)'s, and that the system
just keeps killing and restarting activities?
Small memory leaks can be a problem, like if they were in pid 1 or
something long-lived and critical, but that kind of software really
should be well-audited/tested for this kind of bug. I don't think
Android apps are one of the cases where it matters, though.
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.
