Greg Hudson <[EMAIL PROTECTED]> 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 <*> [EMAIL PROTECTED] 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