From owner-freebsd-arch Sat Jun 2 10:39:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 39EEA37B422; Sat, 2 Jun 2001 10:39:10 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f52Hd9V03943; Sat, 2 Jun 2001 10:39:09 -0700 (PDT) (envelope-from dillon) Date: Sat, 2 Jun 2001 10:39:09 -0700 (PDT) From: Matt Dillon Message-Id: <200106021739.f52Hd9V03943@earth.backplane.com> To: "David O'Brien" Cc: David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> 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 : :On Sat, Jun 02, 2001 at 01:23:05AM -0700, Matt Dillon wrote: :> Yes, I know all that. The problem isn't that you couldn't have an :> unsigned time_t, the problem is that there are vast amounts of software :> already out there that would "break mysteriously" if you did. So, :> like the int<->long problem, the best thing to do is not rock the boat. :> That means for maximum portability time_t has to be a signed long. Not :> int, not unsigned int, not unsigned long... just 'long'. : :There is not enough context here for me to get any idea what the issue :is. This email argued signed vs. unsigned, and that has nothing to do :with time_t being an int. : :Since on IA-32 int == long, the only issue is what ones uses in printf() :and scanf(). I have not seen anyone having a problem with this yet. : :So I ask you to bring this up on freebsd-arch@freebsd.org why time_t :needs to be a long. If you had more multi-platform concerns you would :understand why having as consistent defintions of things is best for :FreeBSD. : :-- :-- David (obrien@FreeBSD.org) Consistency is best, but breaking IA32 to match the already broken Alpha port is the wrong solution. For consistency we should match what Solaris, Linux, and most other UNIX operating systems use, which is 'long'. Our Alpha port is improperly using an int for time_t where nearly every other 64 bit cpu port uses a (64 bit) long. The Alpha guys may decide that it's too late to fix our Alpha port (though personally I think they should just take their lumps and fix it now before it really is too late), but we should absolutely not break the IA32 port because of that. The IA32 port had it correct when it was 'long', allowing software to be written in a portable manner between platforms and OSs (except for our broken Alpha port) without any aches or pains. The commit log says something about catching people who are improperly assuming that time_t is a long. That makes no sense whatsoever since changing it to an int will simply result in not catching people who improperly assume time_t is an int. At least as a long programmers know that there is something special about time_t, even if they still use it improperly. As an int god only knows what kind of assumptions people are going to begin making. time_t is a core type. It has been long from time immemorial and you need a whole lot better explanation then 'improper assumptions of it being a long' to change it. I consider this change totally gratuitous and ungendering totally unnecessary confusion between our use of time_t and other operating system's (such as Linux and Solaris). It not only creates confusion, it also creates portability issues for software (at the very least results in a lot of unnecessary compiler warnings for third party software developed under non-FreeBSD OSs), and perpetuates an already flawed approach to our 64 bit model. It should be backed out. Back in the 16 bit days there was a similar argument about int vs long for things like off_t, and (not so much time_t but the argument was there on the 32 bit side).. and so forth. long won, and for damn good reason. The reasons are still good today. Certain core types like time_t have serious limitations when declared as a fixed width type (int nowadays). long is the perfect solution and you just blew that all to hell with this commit. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message