Date: Fri, 26 Oct 2001 01:21:44 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Peter Wemm <peter@wemm.org> Cc: arch@freebsd.org Subject: Re: 64 bit times revisited.. Message-ID: <Pine.BSF.4.21.0110260109050.8805-100000@InterJet.elischer.org> In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 25 Oct 2001, Peter Wemm wrote: > I know I am going to regret this, but the subject came up again where > we got burnet by code that "knows" that time_t is a long, and on machines > where long != int, this can get ugly when pointers to long and int are > mixed up. > > It was pointed out that *all* the linux 64 bit arches have 64 bit time_t, > so obviously it isn't too hard a problem to solve. > > I did a scan around our tree looking for things where size of time_t > matters. Here's what I found initially: > > sizeof(time_t) exposed: > /etc/pwd.db (pw_change, pw_expire) > /var/run/utmp (ut_time) > /var/log/lastlog (ll_time) > dump/restore tape format (spcl. c_data, d_ddate, etc) > /var/db/acct (ac_btime - begin time of a process) > > notable exceptions where times are explicitly sized: > ufs inode format (has ufs_time_t == 32 bits explicitly) ufs has enough room to fix this.. there has been a field defined in the on disk inode for nanosecs in each of the time values... if we take the lowest 8 bits of that field and re-assign it to be the highest 8 bits of the seconds, then we have time accuracy down to microseconds still and we expand file times by a factor of 256 (which is all of recorded history plus some) we just always set those bits to 0 for the next 37 years and we don;t really lose time resolution and we gain compatibility with the future.. nothing these days has nonosecond resolution there anyhow.... > > 3) Switch to 64 bit time_t on everything including i386. my vote To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0110260109050.8805-100000>