Date: Sat, 27 Oct 2001 17:51:42 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Marcel Moolenaar <marcel@xcllnt.net>, Peter Wemm <peter@wemm.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86, votes Message-ID: <p05101003b800cfd71d2c@[128.113.24.47]> In-Reply-To: <20011027124149.A486@dhcp01.pn.xcllnt.net> References: <200110270636.f9R6aik43419@apollo.backplane.com> <20011027064343.03830380A@overcee.netplex.com.au> <20011027124149.A486@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:41 PM -0700 10/27/01, Marcel Moolenaar wrote:
>Since we're counting votes: I too think we should leave the
>i386 alone.
>
>Changing time_t to long is a good "first step". [..etc..]
>
>In the mean time, being able to use %ld for time_t is *very*
>convenient and truly MI.
So much has been said in this thread, and so many suggestions
offered, that I am not sure anyone could reliably say where
people's votes are.
Here is a suggested way to think about the votes. Let's pick a
scale from 1 to 5, where
1 = "I will fight against this change with all the keys on
my keyboard",
3 = "I am basically neutral on the idea", and
5 = "I am certain that the freebsd project should make this
change".
Now use that scale to vote for the following list of suggested
changes. Each item in the list is for one specific change,
and each would be voted on separately.
a) For the up-and-coming 64-bit platforms (sparc64, IA-64),
FreeBSD 5.0-release should have a 64-bit value for time_t.
b) For the up-and-coming 32-bit platforms (PowerPC),
FreeBSD 5.0-release should have a 64-bit value for time_t.
c) For the existing 32-bit platform (i386),
FreeBSD 5.0-release should have a 64-bit value.
d) For all 32-bit platforms (PowerPC, i386),
iff FreeBSD 5.0-release continues to be a 32-bit value,
then it should be called 'long' instead of 'int'.
My own votes are:
a) 5.0 - Even though I have read all the messages in this
thread, I have not seen one convincing argument for
bringing these new platforms up on a 32-bit time_t,
which then means we will have to plan a migration
to 64-bit time_t at some later date.
b) 4.0 - this does seem like a good idea to me, but I can
also live with a 32-bit time_t on 32-bit platforms.
c) 3.1 - given my votes for a & b, I think I would slightly
prefer to have a 64-bit time_t on i386. I can also
see that even if we do want this, it might still be
better to wait until 6.0 or later to do it.
d) 4.9 - if-and-only-if we are going to have any 32-bit
time_t's, then it makes the most sense (to me)
if they are explicitly 'long' and not 'int'.
Note that I am not debating what any C standards say, and I am
not casting aspersions on what anyone else thinks we should do.
Given that the C standards are so pathetic on this, I recognize
that no matter WHAT we do, it will not be a perfect solution.
So, I am just voting for what I think would be the best action
for the FreeBSD project to take at this time.
I don't really expect anyone to drop what they are doing based
on my vote, but I thought that presenting an explicit list of
"what to vote on" might be helpful to this debate.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
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?p05101003b800cfd71d2c>