Using environment variables without leaking memory?

Rob Landley rob at landley.net
Thu Oct 26 14:43:06 UTC 2006


On Wednesday 25 October 2006 6:20 pm, Dave Dodge wrote:
> On Tue, Oct 24, 2006 at 03:51:35PM -0400, Rob Landley wrote:
> > because what if somebody did a getenv() and kept the pointer around after 
> > doing an unsetenv()?
> 
> Then they're broken by definition.  POSIX/SUS explicitly says that the
> getenv results can be damaged by getenv, setenv, or unsetenv (but by
> no other library function).
> 
> If you're willing to make broken programs break, you can probably
> implement the environment stuff without too much pain.  putenv is
> perhaps the worst of it, though somewhat ironically the rationale for
> keeping it in the Standard was that it's the only guaranteed way to
> avoid memory leaks.

That makes no sense.  If the guaranteed way to avoid leaks is to track the 
memory you feed to putenv() and free it after doing an unsetenv(), then you 
still can't free it afterwards if "damaged" might include freed.  If the 
standard just says you can modify the memory, then to make it longer you have 
to realloc() it, which can move it...

It still sounds just plain mis-designed from the ground up...

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery



More information about the uClibc mailing list