Date: Sat, 27 Oct 2001 13:29:18 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 Message-ID: <200110272029.f9RKTIi56468@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:off_t was not passed by reference in any standard interface. Indeed,
:it was a new invention only a few years old.
So? A pass-by-reference sizing problem is at least as bad as a
pass-by-value sizing problem. C promotes char's and short's to ints
when passing them as parameters, but it doesn't automatically promote
anything to long int.
:time_t is passed by reference in all standard interfaces except
:mktime().
So? That's why we have to roll the syscalls and major library rev. Older
binaries will still run just fine.
:Furthermore, many other systems had longer-than-long off_t (that's
:what the whole Large File Summit thing was about); there are NO other
:systems which have longer-than-long time_t. In those systems, which
:actually cared about standards compliance, the *32/*64 and EOVERFLOW
:hacks introduced by the LFS were used so that standard-compliant
:applications would not break.
:
:-GAWollman
I think the discussion in regards to sizeof(time_t) > sizeof(long) is
a valid one, but I don't see it as a show stopper.
I had issues with 2038 15-20 years ago, I have issues with 2038 now. I
am not going to wait until 2037 for the problem to be fixed. 5.0 is
the perfect place to fix it, and it needs to be fixed for IA32 as well as
for everything else because I'm fraggin sick and tired of people whining
about it for two decades and not particularly interested in hearing more
whining for the next two decades. If time_t can be a double, it damn
well can be an int64_t.
-Matt
:--
:Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
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?200110272029.f9RKTIi56468>