Date: Sat, 27 Oct 2001 15:16:26 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 Message-ID: <200110272216.f9RMGQV64611@apollo.backplane.com> References: <20011027213407.3E3B239F3@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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.
We don't have to. Back in the off_t days a lot of people were
not using prototyped headers or were 'extern'ing C library
routines themselves rather then #includ'ing the correct header.
That did create a problem.
But that was a decade ago. Nearly all the code we care about
today is using prototypes and include files properly. off_t
(not just on FreeBSD) and multi-platform users forced them to start
doing it right. It isn't nearly the issue today that it was
years ago.
Today, 64 bit integer types on 32 bit platforms is an accepted
use of C. They are considered to be and used as basic integer
types.
:> 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
Huh? There is very little to mess with. UFS already has the necessary
fields and they are unused (FreeBSD forces the nanotime fields to 0),
and it can be made 100% backwards compatible.
But, that said, I agree that we don't need to make any changes to
UFS now other then to make sure we convert between 32 and 64 bit
times properly in stat(). Neither do we need to move UFS to 64 bit
block numbers in tandem with 64 bit timestamps. They are completely
separate issues. UFS is a non-issue.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200110272216.f9RMGQV64611>