Date: Sat, 2 Jun 2001 13:05:15 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: "David O'Brien" <obrien@FreeBSD.ORG> Cc: Garance A Drosihn <drosih@rpi.edu>, David Wolfskill <david@catwhisker.org>, arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <200106022005.f52K5FR04823@earth.backplane.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <p05100e0fb73ee9d458f7@[128.113.24.47]> <20010602124907.G31257@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:On Sat, Jun 02, 2001 at 03:33:03PM -0400, Garance A Drosihn wrote:
:>
:> I don't have any strong feeling about what is "right" in this
:> case, but I do think it would be appropriate to back out the
:> change to time_t until the question *is* correctly sorted out.
:
:I don't see why? We can't even agree there is a problem. And if dangous
:kernel commits can stay in, so can this one.
:
:--
:-- David (obrien@FreeBSD.org)
It is really the person making the commit (you) that has the burden
of justification here, not those of us who object to it. Explain why you
believe changing the long to int can be justified in light of the fact
that Solaris and Linux use long (and all the other reasons I iterated!).
Your reasoning so far is extremely weak and not very forward looking.
It is certainly not sufficient to make such a basic change to a core
type stick I think!
It also seems to me that nobody has really considered what is going to
happen 15 years down the line when the importance of being able to
write 203x-safe software becomes paramount. I am concerned about it
*right* *now*, so much so that all the software I write (e.g. Backplane
Inc's billing system software) stores time stamps in text form.
The linux/Solaris/everyone-else crowd uses 'long' precisely because
they assume (rightly) that by the time it matters cpu's will be 64 bit
native. When that time comes (oh wait, it's already here!) the standard
time functions (e.g. time(), gmtime(), localtime()) will already be
using 64 bit time_t's on 64 bit cpu and there will be no need at all
for creating a new API. What about us? Are we going to introduce
time64_t functions for 64 bit platforms with different function names
and force people to use them? Where will our portability to other
platforms be then? Nobody but us will have to use the new API because
everyone else will still be using localtime() and friends. Remember
linux's lseek64()? Remember SGI's? Remember what happened to them?
We don't want to be in that boat.
As much as I would love to change IA32 to use long long, it would be
a disaster to make that sort of change. While long<->int on IA32
does not involve a change in type size, long<->longlong does. But
because 'long' is the defacto standard for time_t, and because it
translates extremely well to 64 bit platforms, we should keep things
consistent and keep using 'long' even on IA32.
I can see an intermediate fix for IA32 64 bit time_t's and that would
be to have a -DTIME64_T compiler flag and then have the time header
files do the right thing (including #define renaming standard time
functions to the 64 bit versions of same). That way people who wanted
64 bit time functions on IA32 could get them. But for any 64 bit
platform, a 64 bit time_t should be standard.
-Matt
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?200106022005.f52K5FR04823>