[Top][All Lists]
[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