Date: Wed, 15 Oct 2003 05:28:08 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Harti Brandt <brandt@fokus.fraunhofer.de> Cc: sparc64@FreeBSD.org Subject: Re: time_t on sparc64 Message-ID: <20031015045429.Q41837@gamplex.bde.org> In-Reply-To: <20031014103446.U45269@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Oct 2003, Harti Brandt wrote:
> On Tue, 14 Oct 2003, Bruce Evans wrote:
>
> BE>On Mon, 13 Oct 2003, Harti Brandt wrote:
> BE>
> BE>> I just discovered that time_t is 32-bit on sparc64. One of the problems
> BE>> is that struct timeval is defined by Posix as
> BE>>
> BE>> struct timeval {
> BE>> time_t tv_secs;
> BE>> suseconds_t tv_usecs;
> BE>> };
> BE>
> BE>This is a bug in POSIX. In BSD, tv_secs has type long which may be,
> BE>and is different from time_t.
>
> Why do you think this is a POSIX bug? Aren't we the odd man out? Now we
AFAIK (not all that far), timevals (or at least most of the things
POSIX uses them for) are BSD things, so POSIX is broken since it is
incompatable with the a reference implementation if not _the_ reference
implementation. POSIX uses timevals mainly for getrusage(), select(),
itimers, get/settimeofday(), utimes() and struct utmpx. All of these
except utmpx are documented in the FreeBSD man pages ias first appearing
in 4.2BSD. FreeBSD doesn't even have struct utmpx. It has struct
utmp, which is documented as first appearing in V6. It is not quite
compatible with V6 here and has actually regressed with respect to
storing times: it uses "int32_t ut_time", but V7 uses "long ut_time".
This regression occurred for binary compatibility reasons in FreeBSD
(Lite2 uses "long ut_time").
> (and MacOS 10) require a workaround for thinks like
>
> printf("%s", ctime(tv.tv_secs));
&
>
> which works perfect on other systems.
> BE>[ffs changes]
> BE>To change time_t to 64 bits, all in-use non-transient data structures
> BE>need to be changed similarly.
>
> I guess we have to do this work before 2038, don't we? If we don't do it
> before 5.2 we have to stick with this until 6.0. Correct?
Yes.
It is too late to change it for 5.n IMO. Every syscall that uses a time_t
or a timeval would need to be duplicated. This would give a lot of
compatibility cruft that would have to be supported forever if the
transition is not carefully managed. We still haven't managed to drop
cruft like olseek() (to support 32-bit off_t's) although the clean break
in 4.4BSD should have made it unnecessary.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031015045429.Q41837>