Date: Sat, 27 Oct 2001 14:34:07 -0700 From: Peter Wemm <peter@wemm.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 Message-ID: <20011027213407.3E3B239F3@overcee.netplex.com.au> In-Reply-To: <200110272114.f9RLEwv64429@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. But thats not the issue. The issue is 'long long' and missing prototypes, &long vs &time_t etc. We cant force the rest of the world to compile everything with -Wmissing-prototypes etc. > 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. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20011027213407.3E3B239F3>