[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] Re: access to Solaris2.5 system? [Re: strftime merge f

From: Jim Meyering
Subject: Re: [Bug-gnulib] Re: access to Solaris2.5 system? [Re: strftime merge from Emacs
Date: Sat, 07 Jun 2003 16:52:18 +0200

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>> Can anyone here compile/run the following program to see if it
>> exits nonzero on a Solaris 2.5 system?
> I no longer have access to 2.5, but I do have 2.5.1 and 2.6, and have
> verified that they have the bug.  But I now see that I gave you a
> oversimplified version of the problem, as you have to have a tzset
> that does real work.  Here's a test case that illustrates the bug; it
> fails on Solaris 2.5.1 and 2.6.  I'm reluctant to use memcmp in the
> test case since I worry it might mishandle tm_* members other than the
> ones required by the standard.
> #include <time.h>
> #include <stdlib.h>
> int
> main ()
> {
>   time_t t1 = 853958121;
>   struct tm *p, s;
>   putenv ("TZ=GMT0");
>   p = localtime (&t1);
>   s = *p;
>   putenv ("TZ=EST+3EDT+2,M10.1.0/00:00:00,M2.3.0/00:00:00");
>   tzset ();
>   exit (p->tm_year != s.tm_year
>         || p->tm_mon != s.tm_mon
>         || p->tm_mday != s.tm_mday
>         || p->tm_hour != s.tm_hour
>         || p->tm_min != s.tm_min
>         || p->tm_sec != s.tm_sec);
> }

Hi Paul,

Thanks for writing that.
Rather than changing strftime's

#if !defined _LIBC && HAVE_TZNAME && HAVE_TZSET

to something like this:


What do you think about using a tzset wrapper/replacement
that does *not* clobber localtime's buffer on losing systems?

IMHO, that is the proper fix.
Then we could remove that #if block from strftime altogether.
Though it'd probably be prudent to add something to ensure
that the new configure-time test has been run, e.g.,

"you must run the autoconf test for a working tzset function"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]