Date: Sat, 2 Jun 2001 13:14:04 -0700 From: "David O'Brien" <obrien@FreeBSD.ORG> To: Matt Dillon <dillon@earth.backplane.com> 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: <20010602131404.M31257@dragon.nuxi.com> In-Reply-To: <200106022005.f52K5FR04823@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Jun 02, 2001 at 01:05:15PM -0700 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>
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.
2. We really don't operate that way around here any more. Sad to say,
but true. For some reason the burdon is now on the receiver.
> 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.
> 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.
> 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)
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?20010602131404.M31257>