Fri Apr 11 06:27:00 GMT 1997
<J Q B> wrote:
>> This parenthetical comment about what these systems "use" is not
>> part of the win32 specification. If there really is Windows NT and
>> Windows 95 software that depends upon sorting, then that is a bug.
>> Not that that has any bearing on the real world, where practical
>> software must accommodate MS's bugs.
The parenthetical comment is quite important. (remember I posted this
bug several months ago). The problem is the way getenv(), _putenv()
handles unsorted environments. This will give unexpected results if
there is no sorting performed.
When I used _putenv() to modify an unsorted list of env variables the
same variable remained in the environmental array in different places
with different values. This caused strange problems where Perl
inherits a different environment then C programs spawned from the same
application. This is because Perl loads the env array into a hash
table manually. So Perl will remember the LAST environmental setting
of the variable while getenv() returns the FIRST setting of the
This is not a question of user coding style or real world compromises.
1) Applications must be able to use OS functions when desired.
2) Duplicate environmental settings should not occur as a result of
using OS functions
To ensure that these simple conditions are met the environment must
be sorted or then environment will enter an inconsistent state as a
result of OS interfaces. This means that the quotation from the
manual is correct:
> To do so, the application must explicitly create the =X environment
> variable strings, get them into alphabetical order (because
> Windows NT and Windows 95 use a sorted environment), and then put
> them into the environment block specified by
The application MUST get them into alphabetical order.
For help on using this list (especially unsubscribing), send a message to
"email@example.com" with one line of text: "help".
More information about the Cygwin