UNIX 2038 bug - looking for a list

[Bill Bradford]

I'm writing an article for publication about the Y2038 bug (UNIX epoch
time_t rolling over to negative because it's 32-bits, etc), and one thing I
*cannot* find is a list of *current* operating systems and what versions
they have (if so) changed time_t to be 64-bit and therefore are not
affected by the bug.  I'm not talking about applications or filesystems
(ext2, etc); I'm talking about the internal system clock itself.

Does anyone know at what versions (or kernel versions) the following OSes
went to a "long" time_t?

- Solaris/SPARC (64-bit)
- Solaris/x86-64
- AIX/PowerPC (64-bit)
- NetBSD on 64-bit platforms
- OpenBSD on 64-bit platforms
- FreeBSD on 64-bit platforms
- Linux on 64-bit platforms
- Mac OS X on 64-bit PowerPC
- Mac OS X on 64-bit x86
- Other "major" UNIX/Linux derivatives I've missed?

Thoughts?  Any ideas?

Bill

--
Bill Bradford
Houston, Texas
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[r.stricklin]

On May 18, 2008, at 8:06 PM, Bill Bradford wrote:

> Does anyone know at what versions (or kernel versions) the following  
> OSes went to a "long" time_t?
>
> - Mac OS X on 64-bit PowerPC
> - Mac OS X on 64-bit x86

OS X typedefs time_t as a __darwin_time_t; __darwin_time_t as long,  
independent of architecture. If you compile with LP64 support (#define  
__LP_64__), you get a 63-bit long, otherwise you get 31 bits (long is  
signed).

time.h
sys/types.h
i386/_types.h
ppc/_types.h
i386/limits.h
ppc/limits.h

That said:

$ file /mach_kernel
/mach_kernel: Mach-O universal binary with 2 architectures
/mach_kernel (for architecture i386): Mach-O executable i386
/mach_kernel (for architecture ppc): Mach-O executable ppc
$

...the kernel in 10.5 is still 32-bit. 2038 looms.

ok
bear
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Bill Bradford]

On Sun, May 18, 2008 at 09:15:33PM -0700, r.stricklin wrote:
> $ file /mach_kernel
> /mach_kernel: Mach-O universal binary with 2 architectures
> /mach_kernel (for architecture i386): Mach-O executable i386
> /mach_kernel (for architecture ppc): Mach-O executable ppc
> $
> ...the kernel in 10.5 is still 32-bit. 2038 looms.

Are you judging that just from the "i386" instead of seeing "x86-64", etc?

What about http://www.apple.com/macosx/technology/64bit.html ?

>From here:

http://www.neowin.net/forum/index.php?automodule=blog&blogid=11&showentry=522

I read "Mac OS X will operate in 64-bit mode with a 32-bit emulation layer
if it is installed on a 64-bit processor (i.e. PowerPC G5):
http://www.apple.com/macosx/features/64bit/"

There's also this:

http://developer.apple.com/macosx/64bit.html

Who knows, who knows..

Bill

--
Bill Bradford
Houston, Texas
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[r.stricklin]

On May 18, 2008, at 9:31 PM, Bill Bradford wrote:

> Are you judging that just from the "i386" instead of seeing  
> "x86-64", etc?

Yes. Compare:

$ file /usr/lib/libc.dylib
/usr/lib/libc.dylib: Mach-O universal binary with 4 architectures
/usr/lib/libc.dylib (for architecture ppc7400): Mach-O dynamically  
linked shared library ppc
/usr/lib/libc.dylib (for architecture ppc64): Mach-O 64-bit  
dynamically linked shared library ppc64
/usr/lib/libc.dylib (for architecture i386): Mach-O dynamically linked  
shared library i386
/usr/lib/libc.dylib (for architecture x86_64): Mach-O 64-bit  
dynamically linked shared library x86_64
$

> What about http://www.apple.com/macosx/technology/64bit.html ?

There is lots of 64-bit in 10.5, just not the kernel.

I suppose it's possible the kernel doesn't use time_t in any typedefs,  
in which case it wouldn't matter whether the kernel was 32-bit or 64-
bit.

ok
bear
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Jochen Kunz]

On Sun, 18 May 2008 22:06:41 -0500
Bill Bradford <mrbill@...> wrote:

> - NetBSD on 64-bit platforms
Currently NetBSD time_t is 32 bits even on LP64 machines. NetBSD is
preparing to switch time_t to an int64_t for all ports (32 bit and 64
bit). But this will not go into 5.0. I expect the switch to happen later this year, after the 5.0 branch has been cut.
--


tsch__,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Zach Lowry]

On May 18, 2008, at 10:06 PM, Bill Bradford wrote:

> - OpenBSD on 64-bit platforms
> - FreeBSD on 64-bit platforms

It's my understanding and belief that both of these are using a 64-bit  
time_t.

--Zach
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Bill Bradford]

On Mon, May 19, 2008 at 04:59:17AM -0500, Zach Lowry wrote:
> On May 18, 2008, at 10:06 PM, Bill Bradford wrote:
>> - OpenBSD on 64-bit platforms
>> - FreeBSD on 64-bit platforms
> It's my understanding and belief that both of these are using a 64-bit
> time_t.

Got somewhere you can point me to, to back this up?  I need to verify for
sure before I put it in the article.

Bill

--
Bill Bradford
Houston, Texas
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Matthew Weigel]

Bill Bradford wrote:
> On Mon, May 19, 2008 at 04:59:17AM -0500, Zach Lowry wrote:
>> On May 18, 2008, at 10:06 PM, Bill Bradford wrote:
>>> - OpenBSD on 64-bit platforms
>>> - FreeBSD on 64-bit platforms
>> It's my understanding and belief that both of these are using a 64-bit
>> time_t.
>
> Got somewhere you can point me to, to back this up?  I need to verify for
> sure before I put it in the article.

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/include/_types.h?rev=1.4&content-type=text/x-cvsweb-markup

Looks like time_t is an int for OpenBSD, even on 64-bit platforms like
amd64 (aka x86-64).
--
  Matthew Weigel
  hacker
  unique@...
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Jonathan C. Patschke]

On Mon, 19 May 2008, Bill Bradford wrote:

>>> - OpenBSD on 64-bit platforms
>>> - FreeBSD on 64-bit platforms
>> It's my understanding and belief that both of these are using a 64-bit
>> time_t.
>
> Got somewhere you can point me to, to back this up?  I need to verify for
> sure before I put it in the article.

[jp@blueshift:~]$ uname -sr
FreeBSD 7.0-RELEASE
[jp@blueshift:~]$ egrep 'typedef.*time_t' /usr/include/time.h
typedef __time_t        time_t;
[jp@blueshift:~]$ egrep 'typedef.*time_t' /usr/include/machine/_types.h
typedef __int64_t       __time_t;               /* time()... */

--
Jonathan Patschke | "There is more to life than increasing its speed."
Elgin, TX         |                                   --Mahatma Gandhi
USA               |
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Zach Lowry]

On May 19, 2008, at 11:15 AM, Matthew Weigel wrote:

> Bill Bradford wrote:
>> On Mon, May 19, 2008 at 04:59:17AM -0500, Zach Lowry wrote:
>>> On May 18, 2008, at 10:06 PM, Bill Bradford wrote:
>>>> - OpenBSD on 64-bit platforms
>>>> - FreeBSD on 64-bit platforms
>>> It's my understanding and belief that both of these are using a 64-
>>> bit time_t.
>> Got somewhere you can point me to, to back this up?  I need to  
>> verify for
>> sure before I put it in the article.
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/include/_types.h?rev=1.4&content-type=text/x-cvsweb-markup
>
> Looks like time_t is an int for OpenBSD, even on 64-bit platforms  
> like amd64 (aka x86-64).

Oops, I had it mixed up. I was working on a problem on OpenBSD not too  
long ago, but the *application* was expecting a 64-bit time_t. OpenBSD  
is always 32-bit like Matthew says.

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]

[1] http://docs.sun.com/app/docs/doc/816-5138/features-1?a=view
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[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@...)
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

[Tom "spot" Callaway]

On Tue, 2008-05-20 at 09:21 +0300, Meelis Roos wrote:
> inlude/linux/jiffies.h

This split out of include/linux/sched.h, which got changed to 64 bit
jiffies in 2003:

http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=8fb1bce44d3bac161c3fd81d70415008b8b984af

Note that this happened during the 2.5 cycle, so 2.6 was always using
64bit jiffies (as far as I can see).

hth,

~spot
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue