[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