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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
