AC_SYS_LARGEFILE: Don’t enlarge time_t by default

Having AC_SYS_LARGEFILE enlarge time_t means that any program that has
already requested large file support will be abruptly migrated to
64-bit time_t (on 32-bit systems) as soon as its configure script is
regenerated with a sufficiently new Autoconf.  We’ve received reports
of several widely used programs and libraries that are not prepared
for this migration, with breakage ranging from annoying (garbage
timestamps in messages) through serious (binary compatibility break
in security-critical shared library) to catastrophic (on-disk data
corruption).

Partially revert f6657256a37da44c987c04bf9cd75575dfca3b60: in the
absence of AC_SYS_YEAR2038, AC_SYS_LARGEFILE will now only add an
--enable-year2038 command line option to configure.  If this option is
used, time_t will be enlarged, allowing people to experiment with the
migration without needing to *edit* the configure script in question,
only regenerate it.

In the process, AC_SYS_LARGEFILE and AC_SYS_YEAR2038 were drastically
overhauled for modularity; it should now be much easier to add support
for platforms that offer large off_t / time_t but not with the standard
feature selection macros.  Also, new macros AC_SYS_LARGEFILE_REQUIRED and
AC_SYS_YEAR2038_REQUIRED can be used by programs for which large off_t /
time_t are essential.

The implementation is a little messy because it needs to gracefully
handle the case where AC_SYS_LARGEFILE and AC_SYS_LARGEFILE_REQUIRED
are both used in the same configure script — or, probably more common,
AC_SYS_LARGEFILE (which invokes _AC_SYS_YEAR2038_OPT_IN) followed by
AC_SYS_YEAR2038 — but if macro B is invoked after macro A, there’s no
way for B to change *what macro A expanded to*.  The best kludge I
managed to find is to AC_CONFIG_COMMANDS_PRE as a m4-level hook that
sets shell variables in an early diversion.

* lib/autoconf/functions.m4 (AC_FUNC_FSEEKO): Rewrite to avoid dependency
  on internal subroutines of AC_SYS_LARGEFILE.

* lib/autoconf/specific.m4 (_AC_SYS_YEAR2038_TEST_INCLUDES): Renamed to
  _AC_SYS_YEAR2038_TEST_CODE.
  (_AC_SYS_YEAR2038): Refactor into subroutines: _AC_SYS_YEAR2038_OPTIONS,
  _AC_SYS_YEAR2038_PROBE, _AC_SYS_YEAR2038_ENABLE.
  (AC_SYS_YEAR2038): Update for refactoring.
  (_AC_SYS_YEAR2038_OPT_IN): New sorta-top-level macro, for use by
  AC_SYS_LARGEFILE, that probes for large time_t only if the
  --enable-year2038 option is given.
  (AC_SYS_YEAR2038_REQUIRED): New top-level macro that insists on
  support for large time_t.

  (_AC_SYS_LARGEFILE_TEST_INCLUDES): Renamed to _AC_SYS_LARGEFILE_TEST_CODE.
  (_AC_SYS_LARGEFILE_MACRO_VALUE, AC_SYS_LARGEFILE): Refactor along same
  lines as above: _AC_SYS_LARGEFILE_OPTIONS, _AC_SYS_LARGEFILE_PROBE,
  _AC_SYS_LARGEFILE_ENABLE.  Invoke _AC_SYS_YEAR2038_OPT_IN at end of
  _AC_SYS_LARGEFILE_PROBE.  MinGW-specific logic moved to YEAR2038
  macros as it has nothing to do with large file support.
  (AC_SYS_LARGEFILE_REQUIRED): New top-level macro that insists on
  support for large off_t.

* tests/local.at (_AT_CHECK_ENV): Also allow changes in CPPFLAGS,
  enableval, enable_*, withval, with_*.

* doc/autoconf.texi, NEWS: Update documentation to match above changes.
  Fix typo in definition of @dvarv.

1 files changed, 31 insertions, 3 deletions

diff --git a/NEWS b/NEWS
index 338addb5..d9c6ed94 100644
--- a/NEWS
+++ b/NEWS
@@ -21,15 +21,43 @@ GNU Autoconf NEWS - User visible changes.
   that you will get a confusing error message if you run autoconf on
   a configure.ac that neglects to use AC_INIT or AC_OUTPUT.
 
-*** AC_SYS_LARGEFILE now arranges for 64-bit time_t if possible.
-
 *** m4sh diversions like BINSH have been renumbered.
   This matters only for uses that, contrary to the documentation
   and despite warnings, use m4_divert with numbered diversions.
 
 ** New features
 
-*** New macro AC_SYS_YEAR2038 for 64-bit time_t.
+*** New macros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
+  These macros attempt to enlarge time_t to 64 bits, on systems where
+  it has historically been only 32 bits wide, and therefore (assuming
+  the usual Unix epoch) cannot represent dates after mid-January of
+  2038 (hence the names).  The difference between the two is that
+  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error
+  out if 64-bit time_t is not available.
+
+  AC_SYS_YEAR2038 will also error out if the host system shows signs of
+  supporting dates after Jan 2038 (e.g. in file timestamps) but it can’t
+  figure out how to get a wider time_t; this failure can be overridden
+  with the --disable-year2038 option.
+
+  Library authors should be cautious about adding these macros to
+  their configure scripts; they can break binary backward compatibility.
+
+*** New macro AC_SYS_LARGEFILE_REQUIRED.
+  This macro is the same as the existing AC_SYS_LARGEFILE except that
+  it will cause 'configure' to error out if 64-bit off_t is not available,
+  and it does not provide a --disable-largefile option.
+
+*** AC_SYS_LARGEFILE now optionally arranges to enlarge time_t.
+  As an experimental measure to make it easier to rebuild old programs
+  with support for dates after Jan 2038, if you regenerate any configure
+  script that uses AC_SYS_LARGEFILE (but not AC_SYS_YEAR2038) using
+  Autoconf 2.72, it will gain an --enable-year2038 option.  When the
+  program is configured with this option, time_t will be enlarged if
+  possible, as if AC_SYS_YEAR2038 had been used.
+
+  Using this option in a library build also potentially breaks binary
+  backward compatibility.
 
 *** AC_USE_SYSTEM_EXTENSIONS now enables C23 Annex F extensions
   by defining __STDC_WANT_IEC_60559_EXT__.