bug-gnulib
[Top][All Lists]
Advanced

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

Re: test results on MacOS X 10.5


From: Jim Meyering
Subject: Re: test results on MacOS X 10.5
Date: Mon, 12 Apr 2010 07:05:11 +0200

Bruno Haible wrote:
...
> #include <config.h>
> #include <time.h>
> #include <stdio.h>
> int main ()
> {
>   static struct tm tm;
>   time_t t;
>
>   tm.tm_sec = 0;
>   tm.tm_min = 0;
>   tm.tm_hour = 0;
>   tm.tm_mday = 1;
>   tm.tm_mon = 0;
>   tm.tm_year = -1900;
>   tm.tm_isdst = -1;
>   t = mktime (&tm);
>   printf ("%ld\n", (long) t);
>   return 0;
> }
> --------------------------------------------------------------------------------------------
>   when run as
>   $ TZ=UTC0 ./a.out
>   produces:
>   -62167132800
>   (this is with the mktime replacement; with the one from the system it 
> produces -1).
>
> So the problem appears really to be with our __mktime_internal.

Hi Bruno,

Nicely reduced.
If you're inclined to investigate further,
I would suggest stepping through that small example in gdb on two systems,
one like the above, and one using glibc.  Then, where they diverge
should indicate the source of the problem.

You might want to reenable the if-0'd code here, just in case
that "verify" is triggered and would explain the problem:

    static inline time_t
    ydhms_diff (long int year1, long int yday1, int hour1, int min1, int sec1,
                int year0, int yday0, int hour0, int min0, int sec0)
    {
      verify (C99_integer_division, -1 / 2 == 0);
    #if 0 /* This assertion fails on 32-bit systems with 64-bit time_t, such as
             NetBSD 5 on i386.  */
      verify (long_int_year_and_yday_are_wide_enough,
              INT_MAX <= LONG_MAX / 2 || TIME_T_MAX <= UINT_MAX);
    #endif




reply via email to

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