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

Probably the "big vendors" using System V based implementations,
if I had to guess...

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

Again, according to the latest standard the lifetime of a return
value of getenv() is until either setenv(), unsetenv(),
or another getenv() call.

"The string pointed to may be overwritten by a subsequent call to
getenv(), setenv(), or unsetenv(),  but shall not be overwritten
by a call to any other function in this volume of IEEE Std 1003.1-2001."

There is also this gem: "The application shall ensure that it does
not modify the string pointed to by the getenv() function."

-- 
Brian Ginsbach                          Cray Inc.