Date: Sat, 2 Jun 2001 22:26:27 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: arch@FreeBSD.ORG Subject: Re: time_t definition is worng Message-ID: <20010602222626.A26556@student.uu.se> In-Reply-To: <20010602124732.F31257@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sat, Jun 02, 2001 at 12:47:32PM -0700 References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124732.F31257@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 02, 2001 at 12:47:32PM -0700, David O'Brien wrote:
> On Sat, Jun 02, 2001 at 10:39:09AM -0700, Matt Dillon wrote:
> > Consistency is best, but breaking IA32 to match the already broken
> > Alpha port is the wrong solution. For consistency we should match
>
> Why is the Alpha port broken? time_t is 32-bits without question. Thus
> it must be an `int' on Alpha, IA-64, and sparc64.
>
>
> > 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.
>
> I 100% disagree -- we should be consistent with FreeBSD and that matters
> more than other non-FreeBSD OS's. To get the same wrap around
> characteristics on our 64-bit platforms as our 32-bit ones, time_t must
> be an `int' on 64-bit platforms.
>
> BTW, NetBSD Alpha and sparc64 (ie, all their 64-bit platforms) have
> _BSD_TIME_T_ as `int'. HP-UX 11 defines it as `int32_t' so it is
> consistent across their 32-bit and 64-bit machines.
>
>
> > 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.
>
> Why do you consider time_t == `int' on i386 broken? Just because of the
> printf() format string?
>
> > 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.
>
> I am more than willing to define time_t as `long long' so it is 64-bits
> across the board.
>
I did a bit of searching in the archives and it seems that this very
question was discussed on the freebsd-alpha list in late Dec./early Jan
1998/1999. As expected there doesn't seem to have been any consensus
on what the "right" thing is. (Since there obviously are valid
arguments on both sides.)
One thing that was mentioned in that discussion though was that FFS
uses time_t in some of the on-disk structures. This means that one
should probably be careful when changing the size of time_t to stay
compatible with existing filesystems.
My take on the situation is as follows:
While it will be necessary to make time_t a 64-bit type eventually to
avoid wrap-around in 2038 I am afraid that this will break many
programs and will require quite a bit of work to fix all problems.
(Yes, it is the Y2K problem all over but with another breakage-date.)
So until everybody is prepared to make that change it is probably a
good idea to continue having time_t as a 32-bit type.
This means that time_t must be defined as 'int' on Alpha.
On i386 it can be either 'int' or 'long'.
It is probably a good idea to have a consistent definition on all the
platforms that FreeBSD runs on. This means that time_t == 'int' is
probably the right thing for now.
When using a time_t in printf(3) or similar situations the 'correct'
thing is to cast the time_t value to a long and treat it is a long.
I.e.
time_t t;
...
printf("%ld",(long)t);
Then the code will work regardless of whether time_t is defined as an
int or as a long. (And regardless of wether sizeof(int) == sizeof(long)
or not.)
(If time_t is defined as a long long then the above code won't work
unless sizeof(long) == sizeof(long long). Code like the above that
assumes that a time_t can fit in a long probably exists in *many*
programs. Changing time_t to a 'long long' might therefore break quite
a lot of things.)
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
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?20010602222626.A26556>