Date: Sun, 13 Oct 2002 08:25:04 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp AT delorie DOT com Subject: Re: profiling with DJGPP In-Reply-To: <10210130615.AA18852@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk On Sun, 13 Oct 2002, Charles Sandmann wrote: > > 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). TZ can be set to a SysV-style string that defines the dates of standard to daylight-saving time transition. This alternative doesn't need any files. Problem solved. > These shouldn't run > significantly slower just because an environment variable is not set. The slow-down is typical only for Unix programs that use gettimeofday. gettimeofday is a system call on Unix, so it's fast, whereas on DOS/Windows we need to do the timezone stuff (because the system clock works in local time, not UTC). However, Unix programs assume TZ is set. So I don't expect any real-life situations with stand-alone programs like the one you thought about, because such a program won't call time-related functions in their inner loops. > If TZ wasn't set before, and the environment wasn't > changed, calling getenv() over and over again doesn't make any sense. I don't disagree, but the change we should try is different from what you suggested. tzsetwall already does TRT when lcl_is_set is -1 (by simply returning); the only thing we should change is that getenv need not be called if the environment didn't change.