From owner-freebsd-arch Sun Jun 3 13:47:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 5EB1737B403 for ; Sun, 3 Jun 2001 13:47:48 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f53KlmM39379 for ; Sun, 3 Jun 2001 13:47:48 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 1D1DC380E; Sun, 3 Jun 2001 13:47:48 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: Poul-Henning Kamp , John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: Date: Sun, 03 Jun 2001 13:47:48 -0700 From: Peter Wemm Message-Id: <20010603204748.1D1DC380E@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 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 and is solely for userland (which pulls in bits of 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