[rescue] UNIX 2038 bug - looking for a list
mroos at linux.ee
Tue May 20 01:21:40 CDT 2008
> I tried on Solaris today. If you build a 64-bit binary with -m64 on 64-bit
> Solaris, time_t will be 64 bits. Otherwise, even on a 64-bit system, it's 32
> bits. 
Well, this us userspace application thing. IIRC the original question
was about system internal time_t, not the one declared for use by
applications. I can well imageine not jusing time_t but some clever
other system inside the kernel and converting it to time_t on needed
syscalls. OTOH, exporting 64-bit time_t to userland would be "strange"
without more than 32-bit internal time storage type. So 64-bit userspace
time_t implies that the kernel _probably_ uses more than 32-bit but it
might not be the same 64 bits as time_t interface shows.
That said, I had a look at Linux kernel sources. inlude/linux/jiffies.h
is the timer tick counter API. It's natively 64-bit on 64-bit arches and
get_jiffies_64() on other arches (implemented in kernel/time.c and using
a lock to keep the 32-bit halves of counter in sync). So it is indeed
64-bit on every arch now, but is not using time_t internally but timer
interrupt count (with varying timer interrupts frequency). This counter
of course wraps around some time earlier than 1 secound counting 64-bit
time_t. In addititon there are other time sources like HPET...
Meelis Roos (mroos at linux.ee)
More information about the rescue