Date: Mon, 4 Jun 2001 03:47:54 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@wemm.org> 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: <Pine.BSF.4.21.0106040325030.50919-100000@besplex.bde.org> In-Reply-To: <20010603082153.E17C3380C@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <machine> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0106040325030.50919-100000>