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