[Toybox] setenv memory leak.

[Josh Gao]

On Mon, Apr 8, 2019 at 1:12 PM Rob Landley <rob at landley.net> wrote:
> Yes, they have to do it themselves because libc is doing it unusably wrong for
> anything that persists and changes environment variables repeatedly.
>
> *shrug* Reinventing this wheel isn't hard, I'd just hoped I wouldn't have to.
> But I didn't complain widely enough long ago, and only musl fixed the leak.

Shells need to keep track of variables separately from the environment to
handle non-exported variables anyway. I suppose you could keep everything
in the environment and keep a list of non-exported variables as well, but
that just seems like more work for no reason.

Making setenv not leak seems impossible in the presence of threaded code,
anyway: you have no way of knowing whether the return value of getenv just got
freed because some other thread came in and called setenv, so the only solution
is basically to just never call setenv (but that fixes your leak, too!).