[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZop17ovc2i3iAK6AoP8mwphEpvvhj-4SvbtzNWEkZroj_A@mail.gmail.com>
Date: Wed, 25 Jun 2025 10:10:00 -0400
From: enh <enh@...gle.com>
To: Rich Felker <dalias@...c.org>
Cc: Jeffrey Walton <noloader@...il.com>, 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>, 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 8:19 PM Rich Felker <dalias@...c.org> wrote:
>
> 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?
no. if the system has to do that, that's considered a negative app
quality signal.
this is like saying "aren't all linux apps expected to leak memory and
be killed by the OOM killer?". sure, you can do that, but expect to
hear complaints.
> 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.
