From owner-freebsd-stable Sat Jun 2 1:23:15 2001 Delivered-To: freebsd-stable@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 15C2237B424; Sat, 2 Jun 2001 01:23:12 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f528N5O98998; Sat, 2 Jun 2001 01:23:05 -0700 (PDT) (envelope-from dillon) Date: Sat, 2 Jun 2001 01:23:05 -0700 (PDT) From: Matt Dillon Message-Id: <200106020823.f528N5O98998@earth.backplane.com> To: David Wolfskill Cc: stable@FreeBSD.ORG, "David O'Brien" Subject: Re: time_t definition is worng References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :>:certainly not the latter. :-) : :> Historically people compared time stamps by subtracting one from :> another. : :Which is a practice that the difftime() function was invented to :replace. : :> If they are unsigned, that breaks horribly (you never get :> a negative result). : :Ummm. With respect, I think the excerpt from "man 3 time" that reads: : : Upon successful completion, time() returns the value of time. Otherwise : a value of ((time_t) -1) is returned and the global variable errno is set : to indicate the error. : :is probably a more significant restriction: both could be gotten around :if time_t were unsigned, but in the mean time (no pun intended!), I suspect :that a lot of naively-coded applications would break mysteriously. : :> Internally there is nothing preventing us from :> treating time_t as an unsigned, er, long. : :Well, I don't write much code (and never have written a lot of it), so :please feel free to take what I wrote with an appropriately-sized :"grain of salt". But it may be worth noting (iin this context) that :the result of difftime() is a double. :-} : :Cheers, :david :-- :David H. Wolfskill david@catwhisker.org 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'. In anycase, I'd like to see the author of the commit (That's you, Dave O'Brien) back it out so we don't have to request it formally. I mean, give me a break... changing a core type to catch people assuming time_t is a long? What about the more likely scenario that people assume it's an int? You're just trading one issue for another (amoung about half a hundred other reasons why it should not be gratuitously changed to an int... like for example 95% of the rest of the world declaring it long). Our IA32 time_t was never broken, this commit breaks it gratuitously for no good reason (and doubly especially no good reason for a core type!). It's our Alpha time_t that's broken. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message