LINUX.IE, website of the Irish Linux Users' Group
Tux rules!

   
Home
New Users
Articles
Download
Projects
Community
Vendors

  Print Version
Email to...
 
Archives:


planetILUG

Recent News

News Archive


Join the
ILUG
on FaceBook


Join the
ILUG
on LinkedIn


Join the
ILUG SETI
Group



















 
 :: Mailing Lists

[ILUG] Linux's 2038 Bug

[ILUG] Linux's 2038 Bug

Paul Jakma paul at clubi.ie
Sat May 7 16:49:50 IST 2005


On Sat, 7 May 2005, Richard Eibrand wrote:

> This data is stored in 32 bits, or units of memory. The first of these bits

On 32 bit machines. time_t is usually same size as long, so it's 
64bit on LP64 machines. 64bit time_t is probably enough to count time 
till the heat death of the universe (presuming it happens within 
292.5 billion years).

> Calculated from the start of January 1 1970, this number would 
> represent the 2038 time and date given at the top. Problems would 
> arise when the system times of computers running on Linux reach

And BSD and Solaris and most other Unixes and Unixish systems 
(VxWorks?) which run on *32bit* hardware.

It can be fixed reasonably easy, just introduce a 64 bit time_t on 
32bit computers:

$ cat test.c
#include <stdio.h>
#include <sys/time.h>

typedef long long time64_t;

int main (void)
{
   time_t t32 = 0x7fffffff;
   time64_t t64 = t32;

   printf ("t32: %d, t64: %lld\n", t32, t64);

   t32 += 1;
   t64 += 1;

   printf ("t32: %d, t64: %lld\n", t32, t64);
}

$ ./test
t32: 2147483647, t64: 2147483647
t32: -2147483648, t64: 2147483648

And hey presto, that's the 32bit time_t problem fixed, even on 32bit 
computers. It'd just need all applications to be recompiled, and the 
inevitable bugs that some apps would have in making assumptions about 
the sizeof time_t - those apps would have problems on 64bit computers 
/today/ anyway.

Even better, we have 30 years to fix this. Let's just wait a while - 
64bit machines will become more and more prevalent over the next 10 
years so that will shake out 64bit time_t bugs in various 
applications. Then one could introduce a time64_t and provide a 64bit 
gettimeofday and let apps that want to be y2k38 safe set some kind of 
WANT_TIME64_T define to be able use it. Twenty years left, and 
already some applications on 32bit platforms could be safe. With ten 
years to go, one could make it the default.

Likely, it will be done closer to the time though. There's no point 
encumbering kernel and userland with a double-word time_t for twenty 
years.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
"You'll pay to know what you really think."
-- J.R. "Bob" Dobbs



More information about the ILUG mailing list
Read this without the formatting.
                                                                                                    

 

Hosted by HEAnet


Maintained by the ILUG website team. The aim of Linux.ie is to support and help commercial and private users of Linux in Ireland. You can display ILUG news in your own webpages, read backend information to find out how. Networking services kindly provided by HEAnet, server kindly donated by Dell. Linux is a trademark of Linus Torvalds, used with permission. No penguins were harmed in the production or maintenance of this highly praised website. Looking for the Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
RSS Version
Powered by Dell