Jordan Abel wrote:
....
hmm - this is really another subject, but on the same page as that:
The implementation shall behave as if no library function calls the
getenv function.
that strikes me as odd. many implementations have lots of library
functions that use environment variables, particularly for
locale-dependent stuff, or for determining the local timezone. Or
are they allowed to look in the environment as long as they don't do
it by calling getenv?
The reason for that requirement is that "the string pointed at [by the
pointer returned by getenv()] ... may be overwritten by a subsequent
call to the getenv() function." This means that you must either
process that string completely (whatever that means for your program),
or you must copy that string to a suitable location, before making
another call to getenv().
The requirement that standard library function calls must act as though
they don't call getenv() means that you can call as many of those
function as you want before saving the result of the getenv() call.
This is particular important when you consider all of the typical uses
of an environment variable. At a minimum, you might want to call
strlen() to find out how long the string is, and members of the
malloc() family to allocate enough space to make a copy of it. If the
string is or contains a file name, it's convenient to know that you can
safely pass it to an fopen() call without worrying about the string
buffer being overwritten.
The requirement can be dealt with in a simple fashion: any environment
strings needed by other standard library functions can be retrieved by
an implementation-specific function similar to getenv(), but which uses
a different buffer to store the string values. Another alternative is
that the standard library functions could save a copy of the current
contents of the buffer, and then restore them from that copy before
returning. This gets a little tricker for the functions which use
callbacks, such as bsearch() and qsort().