amd64/109584: zdump doesn't work
Vasil Dimov
vd at FreeBSD.org
Wed Feb 28 06:50:08 UTC 2007
The following reply was made to PR amd64/109584; it has been noted by GNATS.
From: Vasil Dimov <vd at FreeBSD.org>
To: John Baldwin <jhb at freebsd.org>
Cc: freebsd-amd64 at freebsd.org, Daniel Crandall <dcrandall at simplestar.com>, wollman at freebsd.org, kensmith at freebsd.org, rwatson at freebsd.org, bug-followup at FreeBSD.org
Subject: Re: amd64/109584: zdump doesn't work
Date: Wed, 28 Feb 2007 08:43:37 +0200
On Tue, Feb 27, 2007 at 14:54:14 -0500, John Baldwin wrote:
[...]
> zdump works by trying to enumerate all the possible
> values of time_t. On a 32-bit machine this means going from -2^31 to
> 2^31 - 1. On amd64 which has a 64-bit time_t, this means from from -2^63 to
> 2^63 - 1.
Yes, this is true.
> If you understand exponential math you will see that the zone files aren't
> corrupted, and zdump isn't hung. Rather, it's just taking a long time to
> run.
I think this is not the case. It is actually hung in infinite loop in
localtime(3) in libc. Try the following code on amd64 platform:
--- cut ---
time_t t;
t = -9223372036762365600;
localtime(&t);
--- cut ---
it hangs in this loop:
src/lib/libc/stdtime/localtime.c:
1320 y = EPOCH_YEAR;
1321 #define LEAPS_THRU_END_OF(y) ((y) / 4 - (y) / 100 + (y) / 400)
1322 while (days < 0 || days >= (long) year_lengths[yleap = isleap(y)]) {
1323 long newy;
1324
1325 newy = y + days / DAYSPERNYEAR;
1326 if (days < 0)
1327 --newy;
1328 days -= (newy - y) * DAYSPERNYEAR +
1329 LEAPS_THRU_END_OF(newy - 1) -
1330 LEAPS_THRU_END_OF(y - 1);
1331 y = newy;
1332 }
where days oscillates between -1 and 365, y and newy between
-292277022654 and -292277022655. E.g. try so see what happens if you
enter the loop with days=365 and y=-292277022655.
--
Vasil Dimov
gro.DSBeerF at dv
%
Grelb's Reminder:
Eighty percent of all people consider themselves to be above
average drivers.
More information about the freebsd-amd64
mailing list