Date: Sun, 03 Jun 2001 13:47:48 -0700 From: Peter Wemm <peter@wemm.org> To: Bruce Evans <bde@zeta.org.au> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, John Polstra <jdp@polstra.com>, arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong Message-ID: <20010603204748.1D1DC380E@overcee.netplex.com.au> In-Reply-To: <Pine.BSF.4.21.0106040325030.50919-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Sun, 3 Jun 2001, Peter Wemm wrote: > > One other thing.. ufs/* should probably have int32_t in the on-disk records > > (eg: struct dquot) rather than time_t. > > Yes, that would be no worse than using int32_t in the inodes. Both are > stictly broken, because time_t's might not be representable as int32_t's, > and if time_t's actually needed more than 32 bits then ffs would have a > difficult task compressing their values into 32 bits. In the superblocks etc it is less of an issue since those can be transparently changed to u_int32_t which will get us to 2106 or whatever. We dont (intentionally) boot machines before 1970 any more, unless somebody has invented time travel without telling me. :-) I was under the impression that the Tru64 folks started out with a 64 bit time_t but ended up backing out to 32 bit since so much application software broke due to on-the-wire and on-disk formats changing and not being interchangeable with their other OS's (including Ultrix). However, since linux is using 64 bit time_t, I suspect we can get away with it too now. I dont think Linus wants to repeat the 32 bit off_t nightmare. > > On things like Tru64 and *BSD/alpha, one has to printf a time_t like this: > > time_t t; > > printf("%ld\n", (long)t); > > Otherwise you get stack misalignment. Alpha has suffered from this for qui te > > a while. > > I think the alpha at least doesn't actually suffer from this, because > it pads all args on the stack to 32 bits, so printf("%ld", (int)t) > leaves the stack aligned for the next argument. Also, the padding > seems to be by sign extension or zero extension, and the machine is > little-endian, so va_arg() sees the correct value when it accesses > the int on the stack as a long. I've never checked this or received > a reply for questions/assertions about this. Actually, I think I'm going to have to contradict myself on this.. On the Alpha, the first 5 arguments are passed through in 5 64 bit registers. It only hits the stack for > 64 bit args or for more than 5 args. I dont know how it does alignment on the stack for < 64 bit sizes. Logically it would either be round-everything-to-64-bit-multiple or use natural algnment since the Alpha cannot read/write unaligned values without going to a LOT of trouble. > > While I understand David's concerns, and agree that something needs to be > > done, I wonder if staying with a 32 bit time_t on a 64 bit platform is > > really the right thing to do... Consider: > > It's not "right", just pragmatic. If programs didn't make assumptions, > then 32-bit time_t's would work fine until 2106. This is much further > away than Y2K was before computer hardware existed. People [ab]used negative time_t's to represent time before 1970 and get a little upset when it gets made unsigned. :-) > > [1:16am]/raid/Linux/dists/v2.4/linux/include-120> grep time_t asm-*/posix_t ypes.h > > asm-alpha/posix_types.h:typedef long __kernel_time_t; > > asm-arm/posix_types.h:typedef long __kernel_time_t; > > asm-i386/posix_types.h:typedef long __kernel_time_t; > > ... > > and linux/types.h: > > #ifndef _TIME_T > > #define _TIME_T > > typedef __kernel_time_t time_t; > > #endif > > > > If linux can get away with a 64 bit time_t, then we should be able to > > figure out a way to do so as well. They deal with running 32 bit binaries > > on 64 bit kernels on mips64, sparc64 and ia64 as well. > > Another thing that Linux does better is having a potentially different type > for time_t in the kernel. It seems to do that for a lot of things. But, in the Linux case, there is no real unified userland/libc/etc. Our libc has a somewhat incestuous relationship with the kernel source and kernel includes.. There is no telling whether a <sys/foo.h> file is going to be private to the kernel or something that is intended for userland, or shared. Linux at least has the kernel stuff in <linux/foo.h> and <sys/*> is solely for userland (which pulls in bits of <linux/*> as appropriate. 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?20010603204748.1D1DC380E>