Dominik Kubla wrote:
> Quoting POSIX Programmers Guide, 1st Ed., page 133:
Which is not the POSIX standard, but someone giving an
explanation of the standard to applications programmers
(not operating systems implementors).
> ...While it is typically an unsigned long...
Is simply wrong. Checking the UNIX machines I have access
to (HP, DEC, Sun), none of them have an unsigned time_t.
These machines make up the bulk of the industry, so the
word "typically" just isn't so.
> ...it can be a double or long double.
> Looks as if POSIX and ANSI are (again) at odds...
They are all standard arithmetic types, as required by ANSI C,
so what's the problem?
The base type of time_t can be floating point, thus the return type
of difftime(). What's more, ANSI C allows the actual implementation
to be oqaque: you can have a floating point type being incremented
by 18.2 clock ticks per second and still meet the standard, and
some non-UNIX implementations of the C library do this.
Of course, the UNIX implementation of time_t is traditionally
narrower than allowed by the C standard (as you would expect).
The UNIX implementation of time_t is generally a signed long or
integer, incrementing by seconds, (time_t)0 at 00:00:00 1 Jan 1970
UTC.
How much of this is tradition, and how much is permissible
explains our interest in the precise POSIX wording.
This in turn defines the scope for increasing the size of
time_t on a machine with 32 bit integers and 32 bit longs.
------------------------------
As I said in a previous posting, on these platforms the path
of least resistance would appear to be to wait for the C
standard to define a standard type "long long", implement that
in the C compiler as the non-standard type _long _long is on
those machines now (a 64 bit integer, with overhead due to a
32 bit implementation), and define the base type of time_t
from long or int to long long.
This leads to C library version problems, but that appears to be
unavoidable. A compatibility library isn't difficult to develop.
It may be desirable to break things deliberately at some
stage: a program running a 32 bit time_t against a compatibility
C library will die as badly as a program running a 32 bit time_t
against a real C library in 2038. But this is getting way
ahead of ourselves.
Until ISO C9x is approved by most national standards bodies, and
then implmented in gcc, there is very little that can be done
without changing the size of long -- this would lead to even more
issues than changing the size of time_t.
It is reasonable to expect ISO C, support in gcc, and time_t's base
type as long long on 32 bit architectures well within the next decade,
still leaving plenty of time before 2038.
I humbly suggest that this is a Linux 3.0 issue :-)
Regards,
Glen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:05 EST