amd64/109584: zdump doesn't work

[Vasil Dimov]

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.