From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10210160600.AA21764@clio.rice.edu>
Subject: Re: libc' getenv optimization (patch)
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Wed, 16 Oct 2002 01:00:24 -0500 (CDT)
Cc: uue AT pauzner DOT dnttm DOT ru (Leonid Pauzner), djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1021016073916.20518A@is> from "Eli Zaretskii" at Oct 16, 2002 07:41:02 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > > If we cache getenv() properly in the tzset(), we'll only call it once.
> > Agree. That was my original point, but IZ resist.
> 
> If "IZ" is me, then this is a misunderstanding: I never objected to 
> speeding up time functions.

Eli knows a lot more about the time functions than I do.  There may be
some pathological sequence that I hadn't considered on my inspection,
which is why I'd like him to be comfortable with it or suggest how it's
broken.  For example, tzsetwall() seems to currently be a no-op in DJGPP
(outside ctime) since we call internally tzset() everyplace which will
override it.  My suggested change would actually make it "stick" - and 
I'm not sure if that's right.

I can't find any decent documentation on how it should behave (it's not
even available on some unix boxes, and the Solaris documentation is 
pretty sparse/useless on it).

Once I know, I have suggestions for other patch possibilities if the
current one isn't right...