To:	eliz AT is DOT elta DOT co DOT il
Cc:	djgpp-workers AT delorie DOT com
References:	<10210150631 DOT AA20605 AT clio DOT rice DOT edu>
	<2 DOT 7 DOT 9 DOT 1C51G DOT H41539 AT pauzner DOT dnttm DOT ru>
	<2 DOT 7 DOT 9 DOT 15OOH DOT H4M4AK AT pauzner DOT dnttm DOT ru>
	<2593-Sun27Oct2002011523+0200-eliz AT is DOT elta DOT co DOT il>
Message-Id:	<2.7.9.1OZJT.H4MCDK@pauzner.dnttm.ru>
From:	"Leonid Pauzner" <uue AT pauzner DOT dnttm DOT ru>
Date:	Sun, 27 Oct 2002 05:32:08 +0300 (MSK)
X-Mailer:	dMail [Demos Mail for DOS v2.7.9]
Subject:	Re: libc' getenv optimization (patch3)
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

27-Oct-2002 01:15 Eli Zaretskii wrote:
>> From: "Leonid Pauzner" <uue AT pauzner DOT dnttm DOT ru>
>> Date: Sun, 27 Oct 2002 02:37:32 +0400 (MSD)
>>
>> set_hash_env() now uses a single realloc, if any (literally: only the first
>> allocation in most cases), its weight is nearly as much as 2 old getenv calls
>> and definitely less then putenv().

> What will this do to programs that access environ[] directly?  Since

If you mean such programs *change* environ[] and then call getenv() -
there will be a problem (with many libc functions!), unless the program
increment __environ_changed properly.

> this change resyncs environ[] with the hash table only when `getenv'
> is called (or did I understand your code wrongly?), won't such
> programs break?

My hash table is only used in `getenv', and is resynced inside getenv.
Perhaps it should be declared static - that was your question?
Let we declare my function and variables static.

- Raw text -