[tz] x32

[Paul Eggert]

On 05/30/13 06:16, James Cloos wrote:
> So, based on that one datapoint ☺, 32-bit long and 64-bit time_t should
> work out of the box.

The zdump bugs fixed in the latest proposed patch are fairly
esoteric, and shouldn't be triggered merely by running
'zdump -v America/New_York'.  An example of such a bug
might be something more like this:

   zdump -v -c 2147483647,2147483648 America/New_York

where that 2147483648 will overflow the old zdump on a
machine with 32-bit long and 64-bit time_t even though
the cutoff time is representable both as a time_t and as
a struct tm.

This latter invocation of zdump runs afoul of at least one other
bug in the reference implementation, which I haven't had time
to track down; but one bug at a time.

I should mention one other thing: it's possible that
a machine with 64-bit time_t and 32-bit long will work just
fine with the unpatched zdump etc., even though it mistakenly
tries to stuff a 64-bit quantity into a 32-bit variable.  This
is because in C, signed overflow has undefined behavior, and
some implementations store signed 32-bit quantities in 64-bit
registers, as they are allowed to do -- which means that a
32-bit 'long' value can actually store values up to 2**63,
if you're lucky.