On Tue, Jun 24, 2025 at 08:14:32PM -0400, Jeffrey Walton wrote:
> On Tue, Jun 24, 2025 at 10:18 AM Alejandro Colomar <a...@kernel.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
