Having thought some more about this issue overnight, I believe the
changes to the getenv() rationale that we worked out in yesterday's
teleconference still don't fully take account of putenv(). In the
following paragraph:
In fact, for higher performance of getenv(), the implementation
could also maintain a separate copy of the environment in a data
structure that could be searched much more quickly (such as an
indexed hash table, or a binary tree), and update both it and the
linear list at environ when setenv() or unsetenv() is invoked.
all we did was add putenv() to the list of functions in the last
line. That isn't sufficient. If an application adds a string to
the environment using putenv() and then overwrites that string
with different contents, the separate copy will be out of sync.
Even if the "copy" only contains the name part and a pointer to
the value part in environ[], if the application changes the name
part then the separate copy will still contain the old name.
I suggest replacing the paragraph with:
In fact, for higher performance of getenv(), implementations
that do not provide putenv() could also maintain a separate copy
of the environment in a data structure that could be searched
much more quickly (such as an indexed hash table, or a binary
tree), and update both it and the linear list at environ when
setenv() or unsetenv() is invoked. On implementations that do
provide putenv(), such a copy might still be worthwhile but
would need to allow for the fact that applications can directly
modify the content of environment strings added with putenv().
For example, if an environment string found by searching the
copy is one that was added using putenv(), the implementation
would need to check that the string in environ[] still has the
same name (and value, if the copy includes values), and whenever
searching the copy produces no match the implementation would
then need to search each environment string in environ[] that
was added using putenv() in case any of them have changed their
names and now match. Thus each use of putenv() to add to the
environment would reduce the speed advantage of having the copy.
I would also suggest adding to the app usage, and changing the
rationale, for putenv() ...
At page 1717 line 54880, after:
The setenv() function is preferred over this function.
add (as part of the same paragraph):
One reason is that putenv() is optional and therefore less
portable. Another is that using putenv() can slow down
environment searches, as explained in the RATIONALE for getenv().
At page 1717 line 54882, change:
The standard developers noted that putenv() is the only function
available to add to the environment without permitting memory
leaks.
to:
Refer to the RATIONALE section in [xref to setenv()].
Finally, add to the end of the setenv() rationale (P1858 L59381):
See also the RATIONALE section in [xref to getenv()].
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|