From owner-freebsd-arch Sun Jun 3 10:49:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8B7DC37B405 for ; Sun, 3 Jun 2001 10:49:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA12589; Mon, 4 Jun 2001 03:49:31 +1000 Date: Mon, 4 Jun 2001 03:47:54 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Wemm Cc: Poul-Henning Kamp , John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: <20010603082153.E17C3380C@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Sun, 3 Jun 2001, Peter Wemm wrote: > Poul-Henning Kamp wrote: > > In message <200106022043.f52KhFh35078@vashon.polstra.com>, John Polstra write > s: > Incidently, it is possible to configure gcc with 'long' = 64 bits on i386 > and cross compile. This makes time_t a variable sized thing on i386, and > contributes to the breakage. Also consider x86-64 which will have i386's-with-64-bit longs aren't really i386's. People who configure gcc like this should have a separate directory for it :-). But that would be more work. > 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. > 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 quite > 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. On i386's-with-64-bit-longs, subsequent args on the stack are messed up and va_arg() sees a garbage value (with the top bits from the next arg), but there is no alignment exception by default. > I suspect this is the real issue that David is trying to get addressed. > For portability, we cannot *assume* that time_t == long. It may be int48_t > or goodness knows what on some future arch. We can safely assume that > "long" is suffient to represent a time_t though. However, the reference > ABI for alpha has time_t = 32 bit. Yes. This is the same issue as for off_t. Not much should be assumed. > 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. > [1:16am]/raid/Linux/dists/v2.4/linux/include-120> grep time_t asm-*/posix_types.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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message