Date: Fri, 1 Jun 2001 13:00:59 -0600 From: "Dmitry V. Dvoinikov" <dmitry@ssimicro.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re[2]: time_t definition is worng Message-ID: <149413595408.20010601130059@ssimicro.com> In-Reply-To: <200106011839.f51Idbj86306@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>
next in thread | previous in thread | raw e-mail | index | archive | help
> Matt Dillon:
> time_t should remain 'long' on IA32 (even though sizeof(int) ==
> sizeof(long) on IA32), and it damn well should be 'long' on Alpha ...
I believe you are wrong. If it's "long" on both i386 and Alpha,
data will not be binary compatible.
In fact as far as I understand, the origin of this confusion
is making sizeof(int) == sizeof(long) on i386, which is kind of a stretchy.
Best regards,
Dmitry Dvoinikov
mailto:dmitry@ssimicro.com
Original message follows:
> :On Fri, Jun 01, 2001 at 02:39:33PM +0300, Amir Shalem wrote:
:>> it was always long int,
:>> whenever you want to print time_t
:>> in programs it was always
:>> printf("%ld", (time_t)time);
> :
> :That cast is wrong; if you want to print a long, cast it to long.
> :time_t is (was) only a long on the i386; on the alpha it was an int,
> :and code which assumed it to be a long was unportable. It was changed
> :to help catch exactly this kind of mistake.
> :
> :Kris
> What, are you guys nuts? time_t is 64 bits on 64 bit platforms for
> everyone except us? We may be screwed for 32 bit platforms, but don't
> screw us on 64 bit platforms.
> time_t should remain 'long' on IA32 (even though sizeof(int) ==
> sizeof(long) on IA32), and it damn well should be 'long' on Alpha ...
> the alpha guys should change it if it is currently an int on Alpha.
> Please back out this commit. It is not appropriate to make time_t
> an 'int' on IA32. time_t has been 'long' from time immemorial. This
> is an unbelievably bad commit.
> -Matt
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
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?149413595408.20010601130059>