Re: HEADS UP! MAJOR change to FreeBSD/sparc64

Craig Boston wrote:
[...]
> The biggest problem on i386 is that there's a lot of third party software out 
> there that misbehaves if sizeof(time_t) > sizeof(long), even when recompiled 
> from source.  I don't think this an issue on sparc64/amd64 -- IIRC long is 
> already 64 bits on those platforms.  Only real solutions I can think of at 
> the moment are:
[...]
> 2. Bite the bullet and fix all the broken software.  This is probably the 
> 'correct' approach.  I don't know exactly which specs (POSIX? C99?) apply, 
> but I'm under the impression that no guarantee is made about the size of 
> time_t relative to other basic types.  If someone knows for sure, please 
> correct me.  

I am copying from ISO/IEC 9899:1999, section 7.23.1:

"The types declared are size_t; clock_t and time_t which are arithmetic 
types capable of representing times"

[...]

"The range and precision of times representable in clock_t and time_t is 
implementation-defined."

So, indeed there is no guarantee made regarding the size of time_t 
relative to other basic types.  However, time_t must be an arithmetic 
type, it can not be e.g. a struct.

Another interesting possibility that the standard appears to allow, is 
to change the *precision* of time_t.  For example, if time_t represented 
time in two-second intervals we shift the manifestation of the problem 
to the year 2106.  Unforunatelly, this would affect the same programs 
that would be affected from the values 2**31 - (2**32 - 2) for 
representing time: those that are not using difftime and double for 
calculating and storing time differences.

Diomidis