[Toybox] setenv memory leak.

[Rob Landley]

I'm inching towards reopening the toysh can of worms, and last time I opened it
there was a problem with environment variable memory leaking in libc:

  https://landley.net/notes-2006.html#24-10-2006

Over the years I griped about this to Rich Felker, who fixed it in musl:

  http://git.musl-libc.org/cgit/musl/tree/src/env/setenv.c

But bionic still leaks each entry when you replace it:


https://android.googlesource.com/platform/bionic/+/refs/heads/master/libc/upstream-openbsd/lib/libc/stdlib/setenv.c

Meaning if you do:

  for (i = 0; i<999999999; i++) setenv("this", "that", 1);

It'll leak 9 gigabytes.

This seems suboptimal, and is bad for long-running shell scripts.

I'm also trying to redo the tar "command mode" (does anyone _use_ this? It was
submitted so I _assume_ so but I've never encountered it in the wild) to use
nommu-friendly xpopen_both() and the _easy_ way is to just set the environment
variables in the host before the vfork() but that's resetting the same variables
an aribtrary number of times and if libc can't free the variable memory...

Rob

P.S. I can do it myself with putenv() or my own direct environ() manipulation
but that's not my first choice? Nor is rewriting xpopen() to have a callback
doing arbitrary stuff in the vfork context before it execs, kinda defeats the
point of that function...

P.P.S. I honestly don't care if glibc gets this right or I'd have poked them
about it sometime over the past 15 years. If they can't gnu/do the basic "wait,
how does this work and what happens if" stuff a civilian like me does in passing
that's _their_ gnu/problem.