[tz] problems with unsigned 32-bit time_t coming up
Christos Zoulas
christos at zoulas.com
Mon May 27 23:28:38 UTC 2013
On May 27, 2:58pm, eggert at cs.ucla.edu (Paul Eggert) wrote:
-- Subject: [tz] problems with unsigned 32-bit time_t coming up
| I vaguely recalled someone reporting trouble with the tz database
| on NetBSD or some other BSD in the past few months. The gist of it
| was that this platform has 32-bit 'long' and 64-bit 'time_t', and
| the tz code didn't play nicely on such a system.
|
| To try to catch this sort of thing I'd like to add support for trying
| different time_t types, even if they disagree with the system's
| time_t. I'll send a couple of proposed patches to the list to do that.
| I'll then follow up with a report of a bug in the reference
| implementation that is discovered by the patches, when configured
| to run with an unsigned 32-bit time_t. This isn't the NetBSD
| problem, but hey! at least there's an easy-to-run test
| case that illustrates the bug.
There have been two major bugs I can remember relating to NetBSD's
64 bit time_t.
1. Sun's openjdk mercurial repository got corrupted when I committed some code
from a 32 bit system with 64 bit time_t. Talking about trusting the binary
payload!?!? I believe it was fixed and I hope it was done properly.
2. Postgres assumed the sizeof(time_t) == sizeof(long), and when systems
upgraded to NetBSD-6 and recompiled postgres (because the compatibility
code just works fine), it exposed that postgres bug and none of the
databases would load.
To my knowledge both bugs have been fixed. I don't know of any others?
Does anyone else?
Unfortunately I don't know how to catch those application errors easily,
specially when they use casts...
christos
More information about the tz
mailing list