Discussion:
year2038: new module
(too old to reply)
Bruno Haible
2017-05-13 14:19:06 UTC
Permalink
Raw Message
On native Windows, the job of the 'year2038' module is to make sure
'time_t' is a 64-bit type.

If the system headers and CRT did not already provide support for it,
we would need to deal with
the affected types:
time_t
struct timespec
struct timeval
struct utimbuf
struct stat
struct rusage
and the affected functions:
ctime
difftime
gmtime
gmtime_r
localtime
localtime_r
mktime
time
timegm
clock_gettime
clock_settime
futimens
nanosleep
pselect
utimensat
futimes
gettimeofday
lutimes
select
utime
fstatat
fstat
lstat
stat
getrusage

But fortunately, the system headers are already prepared for it: time_t is
__time64_t by default since MSVC 8 (released in 2005), and mingw has the same
facility (even though it's not enabled by default in 32-bit mingw).


2017-05-13 Bruno Haible <***@clisp.org>

year2038: New module.
* m4/year2038.m4: New file.
* modules/year2038: New file.
* doc/year2038.texi: New file.
* doc/gnulib.texi: Include it.

diff --git a/doc/gnulib.texi b/doc/gnulib.texi
index 9a25553..5cadf46 100644
--- a/doc/gnulib.texi
+++ b/doc/gnulib.texi
@@ -6325,6 +6325,7 @@ to POSIX that it can be treated like any other Unix-like platform.
* Libtool and Windows::
* Large File Support::
* Precise file timestamps on Windows::
+* Avoiding the year 2038 problem::
* Windows sockets::
* Native Windows Support without MSVC Support::
@end menu
@@ -6335,6 +6336,8 @@ to POSIX that it can be treated like any other Unix-like platform.

@include windows-stat-timespec.texi

+@include year2038.texi
+
@include windows-sockets.texi

@include windows-without-msvc.texi
diff --git a/doc/year2038.texi b/doc/year2038.texi
new file mode 100644
index 0000000..de85bc6
--- /dev/null
+++ b/doc/year2038.texi
@@ -0,0 +1,10 @@
+@node Avoiding the year 2038 problem
+@section Avoiding the year 2038 problem
+
+The ``year 2038 problem'' denotes unpredictable behaviour of programs
+that will likely occur in the year 2038, for programs that use a 32-bit
+@samp{time_t} type. See @url{https://en.wikipedia.org/wiki/Year_2038_problem}
+for details.
+
+The gnulib module @samp{year2038} attempts to avoid this problem, by
+ensuring that @code{time_t} is a 64-bit type.
diff --git a/m4/year2038.m4 b/m4/year2038.m4
new file mode 100644
index 0000000..6e21f63
--- /dev/null
+++ b/m4/year2038.m4
@@ -0,0 +1,63 @@
+# year2038.m4 serial 1
+dnl Copyright (C) 2017 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl Attempt to ensure that 'time_t' is a 64-bit type
+dnl and that the functions time(), stat(), etc. return 64-bit times.
+
+AC_DEFUN([gl_YEAR2038_EARLY],
+[
+ AC_REQUIRE([AC_CANONICAL_HOST])
+ case "$host_os" in
+ mingw*)
+ AC_DEFINE([__MINGW_USE_VC2005_COMPAT], [1],
+ [For 64-bit time_t on 32-bit mingw.])
+ ;;
+ esac
+])
+
+AC_DEFUN([gl_YEAR2038],
+[
+ AC_REQUIRE([AC_CANONICAL_HOST])
+ case "$host_os" in
+ mingw*)
+ dnl On native Windows, the system include files define types __time32_t
+ dnl and __time64_t. By default, time_t is an alias of
+ dnl - __time32_t on 32-bit mingw,
+ dnl - __time64_t on 64-bit mingw and on MSVC (since MSVC 8).
+ dnl But when compiling with -D__MINGW_USE_VC2005_COMPAT, time_t is an
+ dnl alias of __time64_t.
+ dnl And when compiling with -D_USE_32BIT_TIME_T, time_t is an alias of
+ dnl __time32_t.
+ AC_CACHE_CHECK([for 64-bit time_t], [gl_cv_type_time_t_64],
+ [AC_COMPILE_IFELSE(
+ [AC_LANG_PROGRAM(
+ [[#include <time.h>
+ int verify_time_t_size[sizeof (time_t) >= 8 ? 1 : -1];
+ ]],
+ [[]])],
+ [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no])
+ ])
+ if test $gl_cv_type_time_t_64 = no; then
+ dnl Just bail out if 'time_t' is not 64-bit, and let the user fix the
+ dnl problem.
+ AC_EGREP_CPP([booboo], [
+ #ifdef _USE_32BIT_TIME_T
+ booboo
+ #endif
+ ],
+ [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])],
+ [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Your system include files surely provide a way to make 'time_t' an alias of '__time64_t'.])])
+ fi
+ ;;
+ *)
+ dnl On many systems, time_t is already a 64-bit type.
+ dnl On those systems where time_t is still 32-bit, it requires kernel
+ dnl and libc support to make it 64-bit. For glibc on Linux/x86, this
+ dnl is work in progress; see
+ dnl <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>.
+ ;;
+ esac
+])
diff --git a/modules/year2038 b/modules/year2038
new file mode 100644
index 0000000..af145b8
--- /dev/null
+++ b/modules/year2038
@@ -0,0 +1,28 @@
+Description:
+Attempt to ensure that 'time_t' is a 64-bit type.
+
+Comment:
+This module should not be used as a dependency from a test module,
+otherwise when this module occurs as a tests-related module, it will
+have side effects on the compilation of the main modules in lib/.
+
+Files:
+m4/year2038.m4
+
+Depends-on:
+
+configure.ac-early:
+AC_REQUIRE([gl_YEAR2038_EARLY])
+
+configure.ac:
+AC_REQUIRE([gl_YEAR2038])
+
+Makefile.am:
+
+Include:
+
+License:
+LGPLv2+
+
+Maintainer:
+all

Loading...