Messages in this thread | | | Date | Wed, 5 Jan 2000 15:32:53 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: time_t size: The year 2038 bug? |
| |
On Wed, 5 Jan 2000 doug@springer.net wrote:
> I have tentatively searched the linux kernel archives for this subject, > but haven't found anything. I have heard that there is talk about > moving this to 64 bits. Has anyone considered this (stupid > question) and who else is interested in this subject. It seems to be > a kernel and a glibc issue. Since I am not currently subscribed to > the list, please cc doug@springer.net for any replies. When time > allows, I intend to experiment with the 64 bit thing and see what > breaks. > -Doug Springer >
If everything that references time_t size variables (in all applications and the OS) are changed, and the applications recompiled, of course nothing will break. However, the problem remains with applications that think that struct timeval { long tv_sec, long tv_usec } is how it works. These applications will have to be fixed. Since ix86 machines are not 64-bits, summation of a 64-bit (long long) is a bit of a problem. I have heard that the current 'C' compilers doesn't do a very good job.
Even incrementing a 64-bit timer tick is a problem because an increment, past zero doesn't set the carry flag. You need to do this:
addl $1, low_word adcl $0, high_word
I think that before 38 years is up, none of us will be using 32-bit machines so, even if I was 10 years old, I wouldn't bother 'fixing' 32-bit machines. Even Intel's new stuff is 64 bits.
Adding stuff to do 'long-long' operations on a 'long' machine will just add wasted CPU cycles. I think you should leave it alone.
Cheers, Dick Johnson
Penguin : Linux version 2.3.35 on an i686 machine (400.59 BogoMips).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |