Subject: RE: Sorting environment
From: [email-masked] (Stephan Mueller)

11 Apr 1997 21:19:04 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Original-To: "'Ken Estes'" <[email-masked]>, [email-masked]
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.8)
Original-Sender: [email-masked]

Sounds like a bug in whatever implementation of _putenv() you are using.
I just typed 'set' on my Windows95 machine, in a DOS box, and the
entries listed look something like:
	winbootdir
	COMSPEC
	PATH
	PROMPT
	CTOOLS_PRJ
	DIRCMD
	...
	BLASTER
	TERM
	CMDLINE

It is conceivable that command.com, in its wackiness is reordering them
just to spite me, but I doubt it.  Parenthetical comment aside, I see no
evidence that the environment is guaranteed to be sorted.  The
parenthetical comment appears to be wrong.

stephan();

> -----Original Message-----
> From:	Ken Estes [SMTP:[email-masked]]
> Sent:	Friday, April 11, 1997 6:28 AM
> To:	[email-masked]
> Subject:	Re: Sorting environment
> 
> 
> 
> <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
> variable.
> 
> 
> 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.
> 
> 
> 
> Ken Estes
> 
> 
> 
> -
> For help on using this list (especially unsubscribing), send a message
> to
> "[email-masked]" with one line of text: "help".
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".