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