Date: Sun, 03 Jun 2001 01:21:53 -0700 From: Peter Wemm <peter@wemm.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: John Polstra <jdp@polstra.com>, arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong Message-ID: <20010603082153.E17C3380C@overcee.netplex.com.au> In-Reply-To: <44610.991550564@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010603082153.E17C3380C>