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

Ok, it was thought about at the meeting.  Some one with enough
muscle wanted there historic implementation to define the way
it had to be. sigh...

We tried not to let that happen at the XNET meetings.
(even to the point of making the existing code not quite meet the
forthcoming version of the standard).

> 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'm sure I didn't think there was an unsetenv()...

That is a (probably) a bug. Although it probably isn't clear
anywhere what the lifetime of the return value of getenv() is.
(I've not read the getenv() RATIONALE).

> > 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.

Bum...


	David

-- 
David Laight: david@l8s.co.uk