Greg Hudson <ghudson(_at_)MIT(_dot_)EDU> writes:
The return value of getenv() is a pointer into the environment; a future
getenv() call will not overwrite it. So it's safe not to copy it unless
you anticipate a putenv(). (And I think it's safe even in the face of a
putenv(), actually.) A judgement call.
Not according to the new POSIX/SUSv3 (and i suspect the original
POSIX):
http://www.opengroup.org/onlinepubs/007904975/functions/getenv.html
The return value from getenv() may point to static data which
may be overwritten by subsequent calls to getenv(), [CX] [Option
Start] setenv(), or unsetenv(). [Option End]
[XSI] [Option Start] On XSI-conformant systems, the return value
from getenv() may point to static data which may also be
overwritten by subsequent calls to putenv(). [Option End]
If you think about it, that makes sense. The environment is an
array of pointers to character buffers, and since what putenv(3)
stores for FOO is often larger than the size of the original FOO,
it will need to get a larger buffer at a different address,
invalidating the original returned address.
I just checked Harbison & Steele, and according to them ISO C
does not allow calls to putenv to modify the getenv return
value, and as seen above, nor does POSIX (though the XSI
extension does). Maybe i'm just not very imaginative at this
late hour, but i don't see another way to implement the
environment without putenv modifying it, so i find it strange
that the two important standards don't allow for it.
Bleh, i hope that made sense. sleep...
--
Eric Gillespie <*> epg(_at_)pretzelnet(_dot_)org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett