> a 64 bit variable, it's good for another 4000 years. Uhhh -- no. If it went from 32 bits to *33* bits, that would get us 4000 years. This gets us more like 16 billion billion years (american billions - 16 x 10^18 is what I mean, but it's off the top of my head...)
> Don't you think you're overstating this just a bit? What about programs > that store time_t's in ints? Or write them out to some kind of storage? Well, NetBSD already has a 64 bit off_t... I think the way most people expect the transition to happen is that *int* will become 64 bit, and things will just deal. Since lots of other things that assume 32 bit ints now are already starting to break (ip addresses won't fit any more, off_t's won't fit, pointers *never* fit on the alpha...) I think that system code will be fine, and legacy code will be the problem that it already is. Note also that for most applications that can't be recompiled, being really clever with the 32-bit ctime in the shared libc will cover a fair number of sins... but I hope not to catch anyone actually doing that :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
