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

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

- Raw text -