Hash :
02e7acf2
Author :
Date :
2021-07-06T15:08:05
doc: clarify which module fixes 32-bit time_t * doc/posix-headers/time.texi: Make it clear that the 32-bit time_t problem is addressed by the year2038 module, not by the time module.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
@node time.h
@section @file{time.h}
POSIX specification:@* @url{https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html}
Gnulib module: time
Portability problems fixed by Gnulib:
@itemize
@item
@samp{struct timespec} is not defined on some platforms.
@item
The macro @code{TIME_UTC} is not defined on many platforms:
glibc 2.15, macOS 10.13, FreeBSD 11.0, NetBSD 7.1, OpenBSD 6.0, Minix 3.1.8, AIX 7.1, HP-UX 11.31, IRIX 6.5, Solaris 11.3, Cygwin 2.9, mingw, MSVC 14, Android 9.0.
@item
Some platforms provide a @code{NULL} macro that cannot be used in arbitrary
expressions:
NetBSD 5.0.
@end itemize
Portability problems fixed by the Gnulib module @code{year2038}:
@itemize
@item
On some platforms where @code{time_t} defaults to 32-bit but can be
changed to 64-bit, functions like @code{stat} can fail with
@code{errno == EOVERFLOW} when a 32-bit timestamp is out of range,
such as with a file timestamp in the far future or past:
glibc 2.34.
@end itemize
Portability problems not fixed by Gnulib:
@itemize
@item
On platforms where @code{time_t} is always 32-bit, functions like
@code{stat} can fail with @code{errno == EOVERFLOW} when a timestamp
is out of range, such as with a file timestamp in the far future or
past; on other such platforms,
the functions silently return the low-order 32 bits of the correct
timestamp. These platforms will be obsolete when 32-bit @code{time_t}
rolls around, which will occur in 2038 for the typical case when
@code{time_t} is signed.
@item
On some platforms the @code{tv_nsec} member of @code{struct timespec}
is not of type @code{long}, but is of type @code{long long} instead:
glibc x32
@end itemize