Date: Mon, 4 Jan 1999 22:08:46 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: don@calis.BlackSun.org (Don) Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: time_t and clock_t Message-ID: <199901042208.PAA19419@usr05.primenet.com> In-Reply-To: <Pine.BSF.4.05.9812241001080.1309-100000@calis.BlackSun.org> from "Don" at Dec 24, 98 10:06:00 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > ... and the 2 cents of mine: > > > > In the year 2038, int will be >= 64 bits anyway (IF we're > > still programming in C by then, which I doubt). So let's > > rather stay compatible and let time_t be an int. In fact, > > we're gonna have problems if it's not an int, because many > > software assumes that it's an int. This might not be good > > style, but it's a fact. > Since we are each giving our 2 cents ... > > Intel is going to Merced soon enough. FreeBSD is going to have to be > ported to Merced too so why not beat the rush and have a fully 64 bit > compatible system. Why should we wait until the last second like all of > the Y2K people did. Let's get the Alpha port using a 64 bit time_t and > this way there will be no worried later on. And if and when Merced comes > out FreeBSD can be a truly 64 bit system ready for the next century. time_t can not be 64 bits until we back out the change that stole the adjacent 32 bits in the time_t values in the FFS inodes to use them for nanoseconds. FFS thought of this problem a *long* time ago, and solved it, but some interloper used the space reserved for solving this problem without reformatting disks without thinking about the consequences. If nanoseconds are needed (they aren't; that's why the kernel clock curtime is a monoclock), then they are *only* needed on the modification time (used by "make" and other dependency calculation related code), and they certainly aren't needed to be adjacent (wrong word order for that), so one of the 16 bit spare fields is sufficient. To be "year 2038 compliant", you must solve the on disk representation problem, not just the in-core representation problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901042208.PAA19419>