From owner-freebsd-arch Sun Jun 3 1:22: 0 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 3DC4937B401 for ; Sun, 3 Jun 2001 01:21:54 -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 f538LsM37338 for ; Sun, 3 Jun 2001 01:21:54 -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 E17C3380C; Sun, 3 Jun 2001 01:21:53 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: <44610.991550564@critter> Date: Sun, 03 Jun 2001 01:21:53 -0700 From: Peter Wemm Message-Id: <20010603082153.E17C3380C@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 Poul-Henning Kamp wrote: > In message <200106022043.f52KhFh35078@vashon.polstra.com>, John Polstra write s: > > >I'd prefer to keep it as "long" at least on the i386, because that's > >what the type was for years before ANSI renamed it to "time_t". > > That, in my mind, is actually a good argument for making it "int" so > that we can flush out those places which don't use time_t well in > advance of the unaviodable change to >32 bits... 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 long = 64 bit but will have to compile and run both ia32 and x86-64 binaries.. This is the same situation as on ia64 which has ia32 execution support. One other thing.. ufs/* should probably have int32_t in the on-disk records (eg: struct dquot) rather than time_t. 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 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. 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: [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; asm-ia64/posix_types.h:typedef long __kernel_time_t; asm-m68k/posix_types.h:typedef long __kernel_time_t; asm-mips/posix_types.h:typedef long __kernel_time_t; asm-mips64/posix_types.h:typedef long __kernel_time_t; asm-mips64/posix_types.h:typedef int __kernel_time_t32; asm-ppc/posix_types.h:typedef long __kernel_time_t; asm-s390/posix_types.h:typedef long __kernel_time_t; asm-sh/posix_types.h:typedef long __kernel_time_t; asm-sparc/posix_types.h:typedef long __kernel_time_t; asm-sparc64/posix_types.h:typedef long __kernel_time_t; asm-sparc64/posix_types.h:typedef int __kernel_time_t32; 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. 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