bug-gnulib
[Top][All Lists]
Advanced

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

Re: CLISP build fails in mktime


From: Bruno Haible
Subject: Re: CLISP build fails in mktime
Date: Sun, 30 Aug 2009 10:42:01 +0200
User-agent: KMail/1.9.9

Hi Paul,

gnulib got a report of a compilation error:
> > cc -DHAVE_CONFIG_H -I. -I/tmp/wip/clisp/work/clisp/modules/syscalls/gllib 
> > -I..    -I/usr/pkg/include -I/usr/include 
> > -I/tmp/wip/clisp/work/clisp/src/gllib  -O2 -mfpmath=sse -msse3 
> > -march=nocona -finline-functions -fomit-frame-pointer -ffast-math 
> > -I/usr/pkg/include -I/usr/include -W -Wswitch -Wcomment -Wpointer-arith 
> > -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare 
> > -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 
> > -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -fPIC 
> > -I/tmp/wip/clisp/work/clisp/src/linkkit/.. -MT mktime.o -MD -MP -MF 
> > .deps/mktime.Tpo -c -o mktime.o 
> > /tmp/wip/clisp/work/clisp/modules/syscalls/gllib/mktime.c
> > /tmp/wip/clisp/work/clisp/modules/syscalls/gllib/mktime.c: In function 
> > 'ydhms_diff':
> > /tmp/wip/clisp/work/clisp/modules/syscalls/gllib/mktime.c:168: error: size 
> > of array 'a' is negative
> > /tmp/wip/clisp/work/clisp/modules/syscalls/gllib/mktime.c: At top level:
> > /tmp/wip/clisp/work/clisp/modules/syscalls/gllib/mktime.c:275: warning: no 
> > previous declaration for 'mktime_internal'
> >
> > NetBSD 5.99.15 i386. The problem relates possibly to 64-bit time_t (just a 
> > guess though).

The code in question is:

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);
  verify (long_int_year_and_yday_are_wide_enough,
          INT_MAX <= LONG_MAX / 2 || TIME_T_MAX <= UINT_MAX);

The failing assertion is the second one.

The situation is that 'int' and 'long' are 32-bit, but 'time_t' is 64-bit.

Why is that verify() there? If the code is supposed to be correct when
'int' and 'long' are 32-bit and 'time_t' is 32-bit as well, why would
changing 'time_t' to 64-bit cause a problem? Recall that
  - time_t is the output type, not the input type,
  - the caller verifies the result against overflow,
  - the year1 and yday1 arguments are computed from 'int' values.

Bruno




reply via email to

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