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>