Date: Sat, 2 Jun 2001 13:40:28 -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: <200106022040.f52KeSJ05088@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> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Sat, Jun 02, 2001 at 01:05:15PM -0700, Matt Dillon wrote:
:> It is really the person making the commit (you) that has the burden
:> of justification here, not those of us who object to it.
:
:1. I feel I have. You keep saying "breakage" but aren't telling me what
: specifically it is. You have not argued a single *functional* point
: here -- only the spelling of the 32-bit type used.
You have not justifed to any reasonable degree why you believe changing
time_t from a long to an int should be done. You have not argued a
single *functional* point for making that change beyond your commit
message, which makes no sense because the problem you site is even
*WORSE* if time_t is an int.
I have repeateed the salient points of my argument several times now.
If you didn't read them, then I recommend you go back to my postings and
read them again. I will summarize:
* Changing from long to int only makes the problems you site as
fixing in your commit message worse. Not better.
* The defacto standard for two decades+ is 'long'. You need a damn
good reason to change it now and so far you haven't presented one.
The onus of proof here is not on me, Brian, it is on you. Explain
why you believe this change, which effects thousands of programs
and goes against the grain of two decades of progress is important
enough to make on IA32.
* The two other platforms we have to maintain compatibility with
the most: Solaris and Linux, use 'long'. NetBSD? OpenBSD? Not
an issue for us. In fact, NetBSD seems to be well on their way
to having an alternate API judging by the kernel changes they've
made. We do not want to follow that path.
* We have the ability to stay consistent between 32 and 64 bit
platforms by defining time_t as 'long' on both, reducing portability
headaches. This is what Solaris is doing. This is what Linux is
doing. This maintains a defacto standard that has been around
forever. We damn well ought to be doing it to.
* Our IA32 implementation is not broken. Breaking it to match the
already broken Alpha distribution is inappropriate. If you are
going to break anything you should break (fix) the Alpha
distribution to use long (64 bits).
:> 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!).
:
:NetBSD, OpenBSD, and HP-UX uses 32bit types for time_t.
:
:
:> Your reasoning so far is extremely weak and not very forward looking.
:
:Forward looking is to make time_t 'long long'. We can do that if you
:like.
Huh? I'm not sure where you got this rot from. I would certainly
never advocate changing the size of the existing time_t on IA32. That
would be virtually guarenteed to create all sorts of breakage. Nor
would I advocate a new API. I would advocate a compiler flag or #define
constant that turns the existing API and time_t into a 64 bit API so
only programs that have been specifically ported to the new standard on
IA32 will use the new standard.
:> It is certainly not sufficient to make such a basic change to a core
:> type stick I think!
:
:I do have backing from another committer for this. In fact one that we
:look to for guidance on these things.
Yes, I saw that. This is a case where Bruce is wrong. And so are you.
:> 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.
:
:Well, if you are concerned about 15 years from you, you would be pushing
:for a 'long long' time_t, not a `long' one.
:
:> 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.
:
:Uh.. I've got $100 that says embedded CPUs will still be 32-bit, not 64.
:FreeBSD does have a goal of running on some embedded CPUs -- PPC and
:StrongARM.
:
:--
:-- David (obrien@FreeBSD.org)
Embedded CPUs have other issues that generally require serious finesse
in regards to program porting. You can hardly use an embedded cpu
as a justification for your change.
-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?200106022040.f52KeSJ05088>