Sure. But practically the amount you leak is infinitesimal.
For a lot of applications that's the right call given the rest of the posix semantics you're constrained to and the kinds and frequency of data you pass via env vars.
For a lot of applications that's the right call given the rest of the posix semantics you're constrained to and the kinds and frequency of data you pass via env vars.
execve seems like the preferable choice on a lot of grounds.
Getenv in a program without setenv is fine in both implementations. Setenv is unusable with all conforming implementations.
To pass environments to children, use execve.
The Linux behavior allows a careful single threaded program to use setenv correctly. The BSD/Solaris behavior makes all usage incorrect, but the incorrectness comes in the form of a memory leak, which is preferable to a security issue, usually.
There's no correct, portable use of setenv. If you call it, it's a bug.
> frequency of data
Practically, if you're moving enough data through setenv that the memory leaked versus the steady state fluctuation of the program is at all visible, you've got much bigger problems.
But it I were implementing POSIX and had to implement it, I would almost certainly make Sun's choice thinking of it as the least evil given the expected use cases.