* David Laight <david@l8s.co.uk> [2003/01/30 09:10]:
> > >>From the current standard at
> > (http://www.opengroup.org/onlinepubs/007904975/functions/putenv.html)
> > 
> >     DESCRIPTION
> >     
> >      The putenv() function shall use the string argument to set
> >      environment variable values. The string argument should point to a
> >      string of the form "name=value". The putenv() function shall make
> >      the value of the environment variable name equal to value by
> >      altering an existing variable or creating a new one. In either
> >      case, the string pointed to by string shall become part of the
> >      environment, so altering the string shall change the environment.
> >      The space used by string is no longer used once a new
> >      string-defining name is passed to putenv().
> 
> Shame it says 'shall' and not 'may'.

The 'shalls' were added in revision 6.  I'm guessing to clarify
the situation.

> That definition is trully horrid!

I guess, but they were following System V semantics.  Also from
the RATIONALE section: "The standard developers noted that putenv()
is the only function available to add to the environment without
permitting memory leaks."

> It also is a memory leak, since if you ever putenv() a malloc()ed
> pointer you never, ever, know when it is safe to free the value.

Hmm, I'm not sure that this is true.  If I putenv() a malloc()ed
pointer and I later unsetenv() it, shouldn't I be able to free the
value?  If your assertion is true how is this is really different
from what currently happens with setenv()/unsetenv().  unsetenv()
currently will not free the string that was malloc()ed by setenv()
either.  I believe to truly prevent memory leaks a much more
complicated put/set/unset would need to be devised.  It would keep
track of which strings are allocated and which are not.  (This is
hinted at by the getenv() RATIONALE section in the current standard.)

> Have you found some code that relies on this beaviour?

The XPG 4 tests! :-)  Note that the GNU folks changed glibc
putenv() to follow the POSIX semantics.

> Otherwise I'd be tempted to add some worms to the 'bugs' section
> and leave the code alone!
> 
> Oh - and file a CR against the posix spec!
> 
> 	David

-- 
Brian Ginsbach                          Cray Inc.