From owner-freebsd-arch Sat Oct 27 14:51:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 1854F37B406; Sat, 27 Oct 2001 14:51:53 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9RLpla136406; Sat, 27 Oct 2001 17:51:47 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: 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> Date: Sat, 27 Oct 2001 17:51:42 -0400 To: Marcel Moolenaar , Peter Wemm From: Garance A Drosihn Subject: Re: time_t not to change size on x86, votes Cc: Matthew Dillon , Mike Smith , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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