Date: Sat, 2 Jun 2001 01:23:05 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: David Wolfskill <david@catwhisker.org> Cc: stable@FreeBSD.ORG, "David O'Brien" <obrien@FreeBSD.ORG> Subject: Re: time_t definition is worng Message-ID: <200106020823.f528N5O98998@earth.backplane.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106020823.f528N5O98998>