Date: Wed, 17 Sep 2008 13:54:28 -0600 From: John Hein <jhein@timing.com> To: John Baldwin <jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: 64 bit time_t Message-ID: <18641.24692.875414.533794@gromit.timing.com> In-Reply-To: <200809171321.45354.jhb@freebsd.org> References: <75968.1221600374@critter.freebsd.dk> <200809171040.36105.jhb@freebsd.org> <18641.9342.134166.77425@gromit.timing.com> <200809171321.45354.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote at 13:21 -0400 on Sep 17, 2008: > On Wednesday 17 September 2008 11:38:38 am John Hein wrote: > > John Baldwin wrote at 10:40 -0400 on Sep 17, 2008: > > > And with amd64/x86-64, it may prove to not really be necessary. > > > > I'm not sure I understand the "may" part. Aren't we already using 64 > > bit time_t natively on amd64? Or maybe you're talking about 32 bit > > compat on amd64. > > Yes, we are, and as newer server-class machines (at least) are predominantly > 64-bit, for at least the server-class market it would seem that boxes will > probably move to an amd64 kernel with a 64-bit time_t w/o requiring lots of > rototilling to support 64-bit time_t on i386. Right. I'm more concerned with planning now for y2038 on 32-bit embedded boxes that may still be around in 30 years. In this case, I think it's easy enough for me to just change my local FreeBSD tree to have time_t be 64 bit and recompile. But that doesn't help those users desperately clinging to their 7.1-RELEASE i386 boxes 30 years from now ;)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18641.24692.875414.533794>