bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

year2038: new module


From: Bruno Haible
Subject: year2038: new module
Date: Sat, 13 May 2017 16:19:06 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-75-generic; KDE/5.18.0; x86_64; ; )

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  <address@hidden>

        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
 
address@hidden 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 @@
address@hidden Avoiding the year 2038 problem
address@hidden 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
address@hidden 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]