HEADS UP! MAJOR change to FreeBSD/sparc64
Diomidis Spinellis
dds at aueb.gr
Fri Mar 19 06:08:25 PST 2004
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
More information about the freebsd-current
mailing list