Using environment variables without leaking memory?

[Dave Dodge]

On Thu, Oct 26, 2006 at 10:43:06AM -0400, Rob Landley wrote:
> On Wednesday 25 October 2006 6:20 pm, Dave Dodge wrote:
> > 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.

Note that I missed that putenv() is also allowed to damage the
setenv() results, on systems where putenv() exists (it is considered
an extension).

> 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 you mean that unsetenv() could possibly free() a string you placed
into the environment with putenv(), I don't see that being as
conforming behavior.  The putenv() string need not have come from
malloc or even writeable storage.  I agree that the interaction
between unsetenv() and putenv() is vague, but I think the descriptions
of the two are enough to say that unsetenv() must not alter or damage
a string that was inserted by putenv().

> If the standard just says you can modify the memory,

The API for putenv() guarantees that the string is placed into environ
and modifying the string after the call shall modify the environment.

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

Yes, it's a total mess.

                                                  -Dave Dodge