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.