On Mon, Apr 8, 2019 at 1:12 PM Rob Landley <r...@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!). _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net