time_t on sparc64 (fwd)

[Joerg Schilling]

>---------- Forwarded message ----------
>Date: Tue, 14 Oct 2003 04:17:34 +1000 (EST)
>From: Bruce Evans <bde at zeta.org.au>
>To: Harti Brandt <brandt at fokus.fraunhofer.de>
>Cc: standards at freebsd.org, sparc64 at freebsd.org
>Subject: Re: time_t on sparc64

>On Mon, 13 Oct 2003, Harti Brandt wrote:

>> I just discovered that time_t is 32-bit on sparc64. One of the problems
>> is that struct timeval is defined by Posix as
>>
>> struct timeval {
>> 	time_t	tv_secs;
>> 	suseconds_t tv_usecs;
>> };

>This is a bug in POSIX.  In BSD, tv_secs has type long which may be,
>and is different from time_t.

No, it is definitely not a POSIX bug. POSIX is consistent and doesn't need to be 
fixed. FreeBSD is inconsistent. You cannot call e.g. ctime(&t.tv_sec)

>> but _timeval.h has
>>
>> struct timeval {
>> 	long	tv_secs;
>> 	suseconds_t tv_usecs;
>> }
>>
>> This means, that our timeval is not Posix compatible. What is the reason
>> for time_t not beeing a long on sparc64?

>time_t was used in some data structures whose layout shouldn't be changed
>even for new arches.  Mainly in ufs in Lite2:

>%%%
>ffs/fs.h:	time_t 	 fs_time;		/* last time written */
>ffs/fs.h:	time_t	 cg_time;		/* time last written */

This looks like an internal implementation problem of the FreeBSD kernel.
This is definitely bejond the scope of a standard. Please note that
introducing an inconsistent user interface is much harder to fix later than
adding a few hacks into the kernel and fix the real kernel problem later.
You have nearly 35 years left....


Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling at fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily