Date: Sun, 28 Oct 2001 01:28:47 +0200 From: Bernd Walter <ticso@cicely8.cicely.de> To: Peter Wemm <peter@wemm.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 Message-ID: <20011028012847.B44659@cicely8.cicely.de> In-Reply-To: <20011027213407.3E3B239F3@overcee.netplex.com.au> References: <200110272114.f9RLEwv64429@apollo.backplane.com> <20011027213407.3E3B239F3@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 27, 2001 at 02:34:07PM -0700, Peter Wemm wrote: > Matthew Dillon wrote: > > Hmm. This is interesting. So far all the time code I've > > looked at in libc is already explicitly written to operate > > with a 64 bit time_t and there do not appear to be any (so > > far) dependancies on 'long' or any other int type assumptions. > > > > Methinks a couple of people have already taken a couple of > > passes on the code. > > Well, time_t used to be 'long', which is 64 bits on 64 bit platforms > so it had to be safe. At least on current it's defined as int. NetBSD does define long, but also use int on 64 bit platforms. > > The only real work is going to be > > rolling the syscalls and some relatively minor adjustments > > to UFS. The rest of the kernel appears to be clean though > > I will need to take a second pass on netinet6 and nwfs. > > Dont mess with UFS! Let Kirk do it properly with UFS2. We dont need > future timestamps in UFS, we actually do have 37 years to solve this one. Agreed. Removing the blocknumber limit is much more important until then. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de 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?20011028012847.B44659>