[musl] Re: alx-0029r3 - Restore the traditional realloc(3) specification

[Jeffrey Walton]

On Tue, Jun 24, 2025 at 10:18 AM Alejandro Colomar <alx@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.

Jeff