From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10210130615.AA18852@clio.rice.edu>
Subject:	Re: profiling with DJGPP
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Sun, 13 Oct 2002 01:15:49 -0500 (CDT)
Cc:	djgpp AT delorie DOT com
In-Reply-To:	<Pine.SUN.3.91.1021013080125.11821E-100000@is> from "Eli Zaretskii" at Oct 13, 2002 08:04:01 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> > A casual inspection of ctime.c (I'm not an expert) looks like to me that
> > at least the first comparison of lcl_is_set should be !=0 instead of >0 
> > to cache the case where TZ is not set.
> 
> lcl_is_set is set to -1 by tzsetwall.  I think it's important to not use 
> cached values if they were set by tzsetwall, since it looks at files, and 
> files could have changed behind our back.  It's the same logic as with 
> not calling getenv, except that with files we have no easy way of knowing 
> when the relevant files stay put.
> 
> I think the _real_ fix is to set TZ.  There are no good reasons why not.

There is one excellent reason not to set TZ - you ship an image which 
is run outside the DJGPP environment (standalone).  These shouldn't run
significantly slower just because an environment variable is not set.

In this case we should just treat it like GMT, cache it, and assume it
doesn't change.  If TZ wasn't set before, and the environment wasn't
changed, calling getenv() over and over again doesn't make any sense.

- Raw text -