Bug#402776: marked as done (zdump -v errors on 64 bit architectures)
Your message dated Mon, 22 Jan 2007 15:04:19 +0100
with message-id <20070122140419.GA19876@amd64.aurel32.net>
and subject line Bug#402776: still exists in 2.3.6.ds1-10
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: zdump -v errors on 64 bit architectures
- From: Robin Lewis <robinl@hp.com>
- Date: Tue, 12 Dec 2006 10:41:32 -0500
- Message-id: <1165938092.9670.26.camel@localhost.localdomain>
Package: libc6.1
Version: 2.3.6.ds1-8
When I invoke 'zdump -v America/New_York' on a 32 bit architecture the
output is correct. But, when execuited on a 64 bit architecture the
first 2 lines of output and the last 2 lines are errors (the min and max
years).
The incorrect ouput on a 64 bit architecture has the last 4 lines
something like:
America/New_York Sun Nov 1 05:59:59 2037 UTC = Sun Nov 1 01:59:59
2037 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 1 06:00:00 2037 UTC = Sun Nov 1 01:00:00
2037 EST isdst=0 gmtoff=-18000
America/New_York 9223372036854689407 = NULL
America/New_York 9223372036854775807 = NULL
but the corrected output has the last 4 lines ending correctly at year
2038 as seen here:
America/New_York Sun Nov 1 05:59:59 2037 UTC = Sun Nov 1 01:59:59
2037 EDT isdst=1 gmtoff=-14400
America/New_York Sun Nov 1 06:00:00 2037 UTC = Sun Nov 1 01:00:00
2037 EST isdst=0 gmtoff=-18000
America/New_York Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 22:14:07
2038 EST isdst=0 gmtoff=-18000
America/New_York Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 22:14:07
2038 EST isdst=0 gmtoff=-18000
The values may change but the '= NULL' is consistant when in error.
The problem is caused by an overflow in the year element of
the tm structure that is used. All elements, except year, of the
structure are safe because their max values are limited, ie. 60 seconds,
60 minutes... but years has no limits.
I have attached a patch for zdump.c that restricts the size of the
absolute max and min values used to compute the year value such that it
will not overflow on 64 bit architectures.
I am using Debian GNU/Linux 2.6.17-2-mckinley ia64
and libc6.1 2.3.6.dsl-8
--- zdump.c.orig 2006-12-11 13:59:19.000000000 -0500
+++ zdump.c 2006-12-11 13:59:27.000000000 -0500
@@ -416,12 +416,14 @@
/*
** time_t is signed.
*/
- register time_t hibit;
+ int hibit;
for (hibit = 1; (hibit * 2) != 0; hibit *= 2)
continue;
absolute_min_time = hibit;
absolute_max_time = -(hibit + 1);
+ if(sizeof(int) == 8)
+ absolute_max_time *= 64;
} else {
/*
** time_t is unsigned.
--- End Message ---
--- Begin Message ---
On Thu, Jan 18, 2007 at 12:17:30PM -0700, dann frazier wrote:
> On Thu, Jan 18, 2007 at 07:38:45PM +0100, Aurelien Jarno wrote:
> > Looking more closely to the manpage it seems there is actually no bug,
> > the program behaves as expected:
> >
> > "For each zonename on the command line, print the time at the lowest
> > possible time value, the time one day after the lowest possible time
> > value, the times both one second before..."
> >
> > So that's normal that the output is different on architectures where
> > time_t has a 64-bit type.
> >
> > -9223372036854775808 and 9223372036854775807 are not really
> > representable in our current gregorian calendar, so those date are
> > displayed as "NULL".
>
> makes sense.
Closing the bug then.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
--- End Message ---
Reply to: