Tzdata2006b.tar.gz, tz32code2006b.tar.gz, and tz64code2006b.tar.gz
The files... ftp://elsie.nci.nih.gov/pub/tzdata2006b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tz32code2006b.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tz64code2006b.tar.gz ...are now available. The files... ftp://elsie.nci.nih.gov/pub/classictzcode.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/classictzdata.tar.gz ...have been removed. The 32-bit code is there for folks who may need it; with providence, there will be little or no need to update it. The 64-bit code reflects the changes circulated earlier on the time zone mailing list. Both the 32-bit code and the 64-bit code share the same data. All SCCS IDs were bumped to "8.1" for this release. --ado
Is tz64code for 64-bit platforms only? Or should it work on 32-bit systems? On an ia32 Linux system, I get a failure (appended). tz32code seems to work Ok. -Bennett + tar xf tz64code2006b.tar.gz + tar xf tzdata2006b.tar.gz + make TOPDIR=/usr TZDIR=/usr/share/zoneinfo ETCDIR=/usr/sbin BINDIR=/usr/bin MANDIR=/usr/share/man CFLAGS=-Os -Dtzname=__tzname -Dtzset=__tzset ALL sed \ -e 's|AWK=[^}]*|AWK=nawk|g' \ -e 's|TZDIR=[^}]*|TZDIR=/usr/share/zoneinfo|' \ <tzselect.ksh >tzselect chmod +x tzselect cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o zic.o zic.c cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o localtime.o localtime.c localtime.c: In function `differ_by_repeat': localtime.c:331: warning: integer overflow in expression cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o asctime.o asctime.c cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o scheck.o scheck.c cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o ialloc.o ialloc.c cp yearistype.sh yearistype chmod +x yearistype cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset zic.o localtime.o asctime.o scheck.o ialloc.o -o zic cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o zdump.o zdump.c cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset zdump.o localtime.o ialloc.o -o zdump cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o difftime.o difftime.c cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o date.o date.c cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o logwtmp.o logwtmp.c cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o strftime.o strftime.c ar r ,lib.a logwtmp.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset date.o localtime.o asctime.o strftime.o \ -lc ,lib.a -o date rm -f ,lib.a + make TOPDIR=/var/tmp/bpmbuild.8216/root/usr TZDIR=/var/tmp/bpmbuild.8216/root/usr/share/zoneinfo ETCDIR=/var/tmp/bpmbuild.8216/root/usr/sbin BINDIR=/var/tmp/bpmbuild.8216/root/usr/bin MANDIR=/var/tmp/bpmbuild.8216/root/usr/share/man INSTALL /zic -y ./yearistype -d /var/tmp/bpmbuild.8216/root/usr/share/zoneinfo -L /dev/null africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera factory backward systemv solar87 solar88 solar89 /zic: wild compilation-time specification of zic_t make: *** [posix_only] Error 1 /usr/bin/bpmbuild: build failed
On Mon, Feb 20, 2006 at 05:30:21PM +0000, Bennett Todd wrote:
Is tz64code for 64-bit platforms only? Or should it work on 32-bit systems?
Ideally it should work on both.
On an ia32 Linux system, I get a failure (appended). tz32code seems to work Ok. [...] cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -c -o localtime.o localtime.c localtime.c: In function `differ_by_repeat': localtime.c:331: warning: integer overflow in expression [...] /zic: wild compilation-time specification of zic_t
Sounds like a bug to me... try adding -DLLONG_MAX=INT64_MAX to your CFLAGS specification and see if that helps. (If so then a #ifdef or two should fix the problem on systems based on a moderately modern glibc, and regardless -DLLONG_MAX should be added to the list of CFLAGS adjustments in the Makefile.) --Ken Pizzini
2006-02-21T04:16:49 Ken Pizzini:
[...] try adding -DLLONG_MAX=INT64_MAX to your CFLAGS specification and see if that helps.
Seems to have. Did get a warning: cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -DLLONG_MAX=INT64_MAX -c -o localtime.o localtime.c localtime.c: In function `differ_by_repeat': localtime.c:331: warning: comparison is always false due to limited range of data type but I still seem to have gotten a working build.
(If so then a #ifdef or two should fix the problem on systems based on a moderately modern glibc, and regardless -DLLONG_MAX should be added to the list of CFLAGS adjustments in the Makefile.)
Actually, I don't do glibc, my system is based on uClibc. -Bennett
On Tue, Feb 21, 2006 at 01:30:51PM +0000, Bennett Todd wrote:
Did get a warning:
cc -DTZDIR=\"/usr/share/zoneinfo\" -Os -Dtzname=__tzname -Dtzset=__tzset -DLLONG_MAX=INT64_MAX -c -o localtime.o localtime.c localtime.c: In function `differ_by_repeat': localtime.c:331: warning: comparison is always false due to limited range of data type
but I still seem to have gotten a working build.
Yeah, that warning is harmless; it is an odd bit of code which is trying to determine if time_t is a floating point type. To the compiler it looks an awful lot like the programmer might have been confused, but in this case the compiles-to-boolean-constant is by design (the test in question needs implementation details that the preprocessor can't help with, so the more usual testing with #if can't be used here).
(If so then a #ifdef or two should fix the problem on systems based on a moderately modern glibc, and regardless -DLLONG_MAX should be added to the list of CFLAGS adjustments in the Makefile.)
Actually, I don't do glibc, my system is based on uClibc.
Er, right... I wasn't thinking straight. <stdint.h> is a *compiler* specific (not library specific) header. Make that "a moderately modern gcc", or even "any compiler supporting C99" that should be automagically supported without requiring a -DLLONG_MAX flag. --Ken Pizzini
Bennett Todd <bet@rahul.net> writes:
localtime.c:331: warning: comparison is always false due to limited range of data type
This is due to what I've always considered to be a bug in GCC. See, for example, <http://lists.gnu.org/archive/html/bug-gnulib/2005-06/msg00091.html>. I've never gotten around to fixing it, but in the meantime I would ignore that message.
(If so then a #ifdef or two should fix the problem on systems based on a moderately modern glibc,
There's no easy way to use #ifdefs, since the values in question (e.g., the number of bits in a time_t) can't be computed by the preprocessor.
-DLLONG_MAX should be added to the list of CFLAGS adjustments in the Makefile.)
Hmm, your compiler has long long and INT64_MAX, but not LLONG_MAX? Which compiler is this? Which header defines INT64_MAX? Does your compiler have stdint.h? If so, does -DHAVE_STDINT_H work? It's what the Makefile recommends.
On Wed, Feb 22, 2006 at 10:28:14PM -0800, Paul Eggert wrote:
(If so then a #ifdef or two should fix the problem on systems based on a moderately modern glibc,
There's no easy way to use #ifdefs, since the values in question (e.g., the number of bits in a time_t) can't be computed by the preprocessor.
I was thinking about a #ifdef for INT64_MAX (but see below), not an #if that does a preprocessor-time check of the time_t; I'm quite aware that the latter can not work.
-DLLONG_MAX should be added to the list of CFLAGS adjustments in the Makefile.)
Hmm, your compiler has long long and INT64_MAX, but not LLONG_MAX? Which compiler is this? Which header defines INT64_MAX? Does your compiler have stdint.h? If so, does -DHAVE_STDINT_H work? It's what the Makefile recommends.
On one of my ia386 systems which uses $ gcc -v 2>&1 | grep version gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) there is no LLONG_MAX defined in stdint.h, but INT64_MAX is defined. But... it is just a fluke that my misguided suggestion worked for Bennett Todd. It was merely the fact that LLONG_MAX was *defined* that fixed his compile by having the compiler "typedef long long int_fast64_t", which happens to work fine with gcc. What LLONG_MAX is set to is irrelevant, as far as the code is concerned; the only reference to it being this one #ifdef. Using -DHAVE_STDINT_H is indeed the correct fix. --Ken Pizzini
Ken Pizzini <tz.@explicate.org> writes:
On one of my ia386 systems which uses $ gcc -v 2>&1 | grep version gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) there is no LLONG_MAX defined in stdint.h, but INT64_MAX is defined.
Well, LLONG_MAX would be in limits.h, not stdint.h. But I checked a x86 GNU/Linux host and I see now that in this environment, LLONG_MAX is not defined, because GCC's <limits.h> has something like this: #if __STDC_VERSION__ >= 199901L # define LLONG_MAX __LONG_LONG_MAX__ #endif and GCC by default doesn't set __STDC_VERSION__ to 199901L, even though it has 'long long' (because it doesn't fully support all of C99). Also, I noticed that this environment has had stdint.h for quite some time, but our current method of guessing HAVE_STDINT_H misses this. GNU/Linux is a pretty common case these days. Here's a patch to private.h that should fix both glitches, so that the tz code works even with pre-C99 GCC and glibc implementations (the usual case today). This patch assumes my earlier patches to private.h. --- private.h 2006/02/23 06:18:32 2006.2.0.5 +++ private.h 2006/02/23 21:16:15 2006.2.0.7 @@ -48,10 +48,6 @@ static char privatehid[] = "@(#)private. #define HAVE_SETTIMEOFDAY 3 #endif /* !defined HAVE_SETTIMEOFDAY */ -#ifndef HAVE_STDINT_H -#define HAVE_STDINT_H (199901 <= __STDC_VERSION__) -#endif /* !defined HAVE_STDINT_H */ - #ifndef HAVE_STRERROR #define HAVE_STRERROR 1 #endif /* !defined HAVE_STRERROR */ @@ -128,20 +124,30 @@ static char privatehid[] = "@(#)private. /* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ #define is_digit(c) ((unsigned)(c) - '0' <= 9) +/* Define HAVE_STDINT_H's default value here, rather than at the + start, since __GLIBC__'s value depends on previously-included + files. (glibc 2.1 and later have stdint.h, even with pre-C99 + compilers.) */ +#ifndef HAVE_STDINT_H +#define HAVE_STDINT_H \ + (199901 <= __STDC_VERSION__ || 2 < (__GLIBC__ + (0 < __GLIBC_MINOR__))) +#endif /* !defined HAVE_STDINT_H */ + #if HAVE_STDINT_H #include <stdint.h> #endif /* !HAVE_STDINT_H */ #ifndef INT_FAST64_MAX -#ifdef LLONG_MAX +/* Pre-C99 GCC compilers define __LONG_LONG_MAX__ instead of LLONG_MAX. */ +#if defined LLONG_MAX || defined __LONG_LONG_MAX__ typedef long long int_fast64_t; -#else /* !defined LLONG_MAX */ +#else /* ! (defined LLONG_MAX || defined __LONG_LONG_MAX__) */ #if (LONG_MAX >> 31) < 0xffffffff Please use a compiler that supports a 64-bit integer type (or wider); you may need to compile with "-DHAVE_STDINT_H". #endif /* (LONG_MAX >> 31) < 0xffffffff */ typedef long int_fast64_t; -#endif /* !defined LLONG_MAX */ +#endif /* ! (defined LLONG_MAX || defined __LONG_LONG_MAX__) */ #endif /* !defined INT_FAST64_MAX */ #ifndef INT32_MAX
2006-02-23T06:28:14 Paul Eggert:
Hmm, your compiler has long long and INT64_MAX, but not LLONG_MAX? Which compiler is this? Which header defines INT64_MAX? Does your compiler have stdint.h? If so, does -DHAVE_STDINT_H work? It's what the Makefile recommends.
gcc 3.3.1 with uClibc-0.9.28 (no glibc at all). stdint.h defines INT64_MAX. And yes, -DHAVE_STDINT_H does seem to work, thanks! -Bennett
Bennett Todd <bet@rahul.net> writes:
localtime.c:331: warning: integer overflow in expression /zic: wild compilation-time specification of zic_t
Both of those are symptoms of the same problem: you compiled the code in such a way that the code thinks there is no 64-bit integer support. Here's a proposed patch that will catch this problem earlier and make the fix more obvious: --- private.h 2006/02/22 00:24:05 2006.2.0.2 +++ private.h 2006/02/23 06:18:32 2006.2.0.5 @@ -136,6 +136,10 @@ static char privatehid[] = "@(#)private. #ifdef LLONG_MAX typedef long long int_fast64_t; #else /* !defined LLONG_MAX */ +#if (LONG_MAX >> 31) < 0xffffffff +Please use a compiler that supports a 64-bit integer type (or wider); +you may need to compile with "-DHAVE_STDINT_H". +#endif /* (LONG_MAX >> 31) < 0xffffffff */ typedef long int_fast64_t; #endif /* !defined LLONG_MAX */ #endif /* !defined INT_FAST64_MAX */
"Olson, Arthur David \(NIH/NCI\) [E]" <olsona@dc37a.nci.nih.gov> writes:
ftp://elsie.nci.nih.gov/pub/tzdata2006b.tar.gz ftp://elsie.nci.nih.gov/pub/tz32code2006b.tar.gz ftp://elsie.nci.nih.gov/pub/tz64code2006b.tar.gz
The 32-bit code is there for folks who may need it; with providence, there will be little or no need to update it.
This means we'll need to update the instructions in tz-link.htm, which currently say this: wget 'ftp://elsie.nci.nih.gov/pub/tz*.tar.gz' gzip -dc tzcode*.tar.gz | tar -xf - gzip -dc tzdata*.tar.gz | tar -xf - and this won't work nicely, due to the two code tarballs overridding each other. The names tz32code2006b.tar.gz and tz64code2006b.tar.gz are a bit confusing, since people might naturally get confused into thinking that the tarballs are for 32-bit and 64-bit development platforms, or for 32-bit and 64-bit runtime platforms, whereas neither is the case: they are really for 32-bit and 64-bit tz files, which is a different matter. Here's an idea. How about if we rename tz32code2006b.tar.gz to pre2038-tzcode2006b.tar.gz, and rename tz64code2006b.tar.gz back to tzcode2006b.tar.gz? That way, I won't have to change tz-link.htm (so it's less work for me :-), and also, users will be able to see more clearly why one might prefer the current to the previous version. Also, this naming convention fits in better with the recently-removed 'classictzcode' and 'classictzdata' convention. If you still prefer the current naming style, please let me know, so that I can propose a patch to tz-link.htm. Thanks.
Previously the tz code used "#ifdef __STDC__" to check whether the C compiler is compatible with C89 or later, but tz64code2006b changes this to "#if __STDC__". This change has an undesirable affect on Solaris, where Sun's C compiler by default defines __STDC__ to 0; you must give it an option before it defines __STDC__ to 1. (This is because Sun enables certain traditional but incompatible extensions like stdio.h's fileno by default, and __STDC__==0 signals this.) As a result, Sun's C compiler now compiles in K&R mode, and this doesn't check the types as well. Here is a proposed patch to revert to the previous way of doing things. If you like, I can propose a further patch to remove support for K&R C. This will simplify the code and ease our maintenance burden, as nobody uses K&R C compilers any more except for computer museums (which shouldn't count). =================================================================== RCS file: RCS/date.c,v retrieving revision 2006.2 retrieving revision 2006.2.0.1 diff -pu -r2006.2 -r2006.2.0.1 --- date.c 2006/02/20 15:08:17 2006.2 +++ date.c 2006/02/21 21:07:30 2006.2.0.1 @@ -352,7 +352,7 @@ dogmt() /*ARGSUSED*/ static void -#if __STDC__ +#ifdef __STDC__ reset(const time_t newt, const int nflag) #else /* !__STDC__ */ reset(newt, nflag) @@ -623,7 +623,7 @@ register const struct tm * const btmp; #define ATOI2(ar) (ar[0] - '0') * 10 + (ar[1] - '0'); ar += 2; static time_t -#if __STDC__ +#ifdef __STDC__ convert(register const char * const value, const int dousg, const time_t t) #else /* !__STDC__ */ convert(value, dousg, t) @@ -734,7 +734,7 @@ const time_t t; */ static void -#if __STDC__ +#ifdef __STDC__ checkfinal(const char * const value, const int didusg, const time_t t, @@ -804,7 +804,7 @@ const time_t oldnow; } static void -#if __STDC__ +#ifdef __STDC__ iffy(const time_t thist, const time_t thatt, const char * const value, const char * const reason) #else /* !__STDC__ */ =================================================================== RCS file: RCS/localtime.c,v retrieving revision 2006.2 retrieving revision 2006.2.0.1 diff -pu -r2006.2 -r2006.2.0.1 --- localtime.c 2006/02/20 15:08:17 2006.2 +++ localtime.c 2006/02/21 21:07:30 2006.2.0.1 @@ -602,7 +602,7 @@ register const char * strp; */ static const char * -#if __STDC__ +#ifdef __STDC__ getqzname(register const char *strp, const int delim) #else /* !__STDC__ */ getqzname(strp, delim) =================================================================== RCS file: RCS/zdump.c,v retrieving revision 2006.2 retrieving revision 2006.2.0.1 diff -pu -r2006.2 -r2006.2.0.1 --- zdump.c 2006/02/20 15:08:17 2006.2 +++ zdump.c 2006/02/21 21:07:30 2006.2.0.1 @@ -130,7 +130,7 @@ static char elsieid[] = "@(#)zdump.c 8.1 #endif /* !defined TZ_DOMAIN */ #ifndef P -#if __STDC__ +#ifdef __STDC__ #define P(x) x #else /* !__STDC__ */ #define P(x) () @@ -475,7 +475,7 @@ const long y; } static time_t -#if __STDC__ +#ifdef __STDC__ hunt(char *name, time_t lot, time_t hit) #else /* !__STDC__ */ hunt(name, lot, hit) @@ -552,7 +552,7 @@ struct tm * oldp; } static void -#if __STDC__ +#ifdef __STDC__ show(char *zone, time_t t, int v) #else /* !__STDC__ */ show(zone, t, v) =================================================================== RCS file: RCS/private.h,v retrieving revision 2006.2 retrieving revision 2006.2.0.1 diff -pu -r2006.2 -r2006.2.0.1 --- private.h 2006/02/20 15:08:17 2006.2 +++ private.h 2006/02/21 21:07:30 2006.2.0.1 @@ -156,7 +156,7 @@ typedef long int_fast64_t; */ #ifndef P -#if __STDC__ +#ifdef __STDC__ #define P(x) x #else /* !__STDC__ */ #define P(x) ()
participants (4)
-
Bennett Todd -
Ken Pizzini -
Olson, Arthur David (NIH/NCI) [E] -
Paul Eggert