Mail Archives: djgpp/2002/10/13/02:44:41
> > > 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.
But the additional "installation" step for users to set an environment
variable - which is what we are trying to avoid.
> > 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.
Not. Anything which calls stat/fstat calls mktime(), which calls
tzset() each time, which calls getenv() each time, unless we fix the
caching.
> > 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.
If you look at tzset():
if lcl_is_set == -1, then
we call getenv()
notice it's still null
then call tzsetwall() again, which does nothing
then returns.
My suggestion is that if lcl_is_set !=0 and environment hasn't changed,
then return. This does the exact same thing, and avoids all the extra
getenv calls. I may be missing something.
- Raw text -