From owner-freebsd-arch Fri Oct 26 0:12:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 06B3537B406 for ; Fri, 26 Oct 2001 00:12:10 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA08900; Fri, 26 Oct 2001 01:21:45 -0700 (PDT) Date: Fri, 26 Oct 2001 01:21:44 -0700 (PDT) From: Julian Elischer To: Peter Wemm Cc: arch@freebsd.org Subject: Re: 64 bit times revisited.. In-Reply-To: <20011025233602.587C63808@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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