Date: Wed, 23 Dec 1998 09:21:28 +1300 (NZDT) From: Jonathan Chen <jonc@pinnacle.co.nz> To: "Kaleb S. KEITHLEY" <kaleb@ics.com>, Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: time_t and clock_t Message-ID: <Pine.SCO.3.96.981223091007.7216D-100000@kiwi.pinnacle.co.nz> In-Reply-To: <367FB148.778A1EC3@ics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Dec 1998, Kaleb S. KEITHLEY wrote:
> Hidetoshi Shimokawa wrote:
> >
> > kaleb> > According to /usr/include/machine/ansi.h, time_t and clock_t are "int" on
> > kaleb> > alpha and "long" on i386 respectively. I know "int" on alpha and "long" on
> > kaleb> > i386 are same size 32bit, but I don't think it's resonable that time_t on
> > kaleb> > alpha is "int".
> > kaleb>
> > kaleb> FWIW, time_t and clock_t are also int on Digital Unix.
> > kaleb>
> > kaleb> > At least, "tv_sec" part of timeval is declared as "long".
> > kaleb> > Why don't we change time_t as "long"?
> > kaleb>
> > kaleb> Are time_t and clock_t supposed to be 32-bit types? I'll have to check
> > kaleb> my POSIX specs when I get to work.
> >
> > I don't have POSIX specs, so please let me know what specs says.
>
> Neither POSIX nor XPG require any particular type, only that it be large
> enough to hold a particular range of values; e.g. time_t must be large
> enough to hold a count of the number of seconds in a day, a number that
> easily fits in an int.
Here's my 2 cents:
time_t should be `long' ie 64 bits, 'cos once 2038(?) rolls around
we're gonna have problems with time(3) - which gets used heaps -
if we still stuck with 32 bits.
IMHO, Digital really made a bad boo-boo with sticking to 32 bits.
Jonathan Chen
----------------------------------------------------------------------
"Everything in excess, moderation is for monks!"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SCO.3.96.981223091007.7216D-100000>