[rescue] UNIX 2038 bug - looking for a list

[Meelis Roos]

> 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. [1]

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)