Date: Fri, 16 Oct 2009 14:48:27 +0200
From: yyyyyyyyyyyyyyy@xxxxxxxxxxxxxxxxxxx (Joerg Schilling)
To: yyy@xxxxxxxxxxxxx, The Austin Group
Subject: Re: bug 167 needs more rationale changes

Geoff Clare <yyy@xxxxxxxxxxxxx> wrote:

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

How about adding a note that the "official" putenv() implementation
needs to check whether the environ[] pointer did change compared to the
last time the efficient structure was build?

I have no problems with disallowing to modify single strings inside environ[],
but I would still like to be able to have a private management of environ[]
in a program.

Jörg

-- 
 EMail:yyyyy@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
       yy@xxxxxxxxxxxxxxx                (uni)  
       yyyyyyyyyyyyyyy@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily