Date: Sun, 03 Jun 2001 13:47:48 -0700 From: Peter Wemm <peter@wemm.org> To: Bruce Evans <bde@zeta.org.au> 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: <20010603204748.1D1DC380E@overcee.netplex.com.au> In-Reply-To: <Pine.BSF.4.21.0106040325030.50919-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <sys/foo.h> 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 <linux/foo.h> and <sys/*> is solely for userland (which pulls in bits
of <linux/*> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010603204748.1D1DC380E>