[dfox]

The whole putenv()/setenv()/unsetenv()/environ API is inconsistent hack that is essentially impossible to implement without introducing memory leak in at least one of these operations without introducing some complex additional book keeping. The good news is that there aren't that many reasons to actually use these functions, as only reasonable usecase for modifying environment is changing environment of spawned subprocesses, which can be done by constructing your own environ and passing it as envp argument to exec().

On the other hand the memory leak is mostly negligible and one would assume that for reasonable program that calls setenv (ie. does not call setenv in a loop) probably smaller than cost of the aforementioned extra book keeping.

[bigmessowires]

I used the older uC-libc, not the newer uClibc (no dash in the name). You're right. There's a tiny leak in this version of setenv(), when you set a value for an environment var that already exists. It leaks the old value, which seems to be an intentional design choice, in case anything was holding on to a pointer to it.