Date: Sat, 2 Jun 2001 13:49:01 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: arch@freebsd.org Cc: ertr1013@student.uu.se Subject: Re: time_t definition is worng Message-ID: <200106022049.f52Kn1W35106@vashon.polstra.com> In-Reply-To: <20010602222626.A26556@student.uu.se> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124732.F31257@dragon.nuxi.com> <20010602222626.A26556@student.uu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20010602222626.A26556@student.uu.se>, Erik Trulsson <ertr1013@student.uu.se> wrote: > > I did a bit of searching in the archives and it seems that this very > question was discussed on the freebsd-alpha list in late Dec./early Jan > 1998/1999. As expected there doesn't seem to have been any consensus > on what the "right" thing is. (Since there obviously are valid > arguments on both sides.) > > One thing that was mentioned in that discussion though was that FFS > uses time_t in some of the on-disk structures. This means that one > should probably be careful when changing the size of time_t to stay > compatible with existing filesystems. Hmm, that's an excellent point. Thank you for researching the previous discussions. Since only the kernel mess with the filesystem bits directly, the fact that a 32-bit time_t is used in FFS needn't be a show-stopper for moving to a 64-bit type in userland. (A few utilities such as newfs, fsck, and tunefs might need to be tweaked too.) Though if we didn't eventually increase time_t's size in FFS too, it wouldn't do us much good to widen it anywhere else. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa 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?200106022049.f52Kn1W35106>