Date: Fri, 1 Jun 2001 14:10:55 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: "Dmitry V. Dvoinikov" <dmitry@ssimicro.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Re[4]: time_t definition is worng Message-ID: <200106012110.f51LAt388881@earth.backplane.com> References: <20010601135122.A66182@sunbay.com> <Pine.BSF.4.33_heb2.09.0106011437410.43119-100000@active.ath.cx> <20010601044526.A30739@xor.obsecurity.org> <200106011839.f51Idbj86306@earth.backplane.com> <149413595408.20010601130059@ssimicro.com> <200106011931.f51JVjx87071@earth.backplane.com> <14419530753.20010601143955@ssimicro.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:> Matt Dillon:
:> The data *ISN'T* SUPPOSED TO BE BINARY COMPATIBLE!
:
:Correct. But then there is no difference at all.
:You may typedef double time_t; :)
:
:And I can easily see where it can lead to bugs,
:pretty difficult to find. Therefore I'm still on the
:typedef int time_t; side.
:
:Best regards,
:Dmitry Dvoinikov
:mailto:dmitry@ssimicro.com
There is a difference. time_t is a long on just about
every single system in existance except, as of a week
or two ago, ours. What kind of bullshit is that? The
nice thing about having time_t be a long is that
it magically becomes 64 bits on nearly all 64 bit platforms
(except our alpha port for some ungodly reason that I
can't fathom). And now because somebody gets it into
their head that this defacto standard for time_t somehow
introduces bugs it is decided that we are going to go
against the grain of every single other system
in existance and turn our time_t to an int? I don't
think so. It was treating time_t as an int that created
the holy mess in the 16 bit PC world two decades ago, we
are NOT revisiting that idiocy. Making it an int will
potentially result in even more bugs being introduced then
when it was a long. At least as a long people know it has
to be treated 'special'. There is a huge amount of third party
code that just assumes it is a long now and we shouldn't
gratuitously start generating compile time warnings
for said code. Our stupid change is not going to cause
third party programmers to change their ways. This
commit solves nothing yet creates the potential for a lot
of confusion.
This change should be backed out immediately. It was not
well thought through and is totally inappropriate given
how other systems handle time_t. time_t is too fragile
to screw around with on an established platform, I don't
know what you people were thinking.
-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?200106012110.f51LAt388881>