Re: On time64 and Large File Support

[Zack Weinberg]

On Sun, 25 Dec 2022 14:19:11 -0500, Paul Eggert wrote:
> I reviewed your patch and had the following thoughts.
> 
> * Gnulib doesn't need AC_SYS_LARGEFILE_REQUIRED or
> AC_SYS_YEAR2038_REQUIRED and they're easy for users to do on their own
> with a simple AS_IF, so let's omit these variants for now, to keep
> things simpler.

I disagree with this.  I think it’s important for Autoconf to provide
a built-in, declarative, clearly documented and officially supported
mechanism for packages to declare that they *need* 64-bit off_t and/or
64-bit time_t, rather than just *supporting* them.  This is because,
from the earlier discussion, the surviving Linux–based distributions
for ILP32 ABIs might choose *not* to migrate to building everything
with _TIME_BITS=64 or even with _FILE_OFFSET_BITS=64, believing it
more important to preserve binary backward compatibility with
libraries whose ABI changes as a result of either of those macros.
They’re going to try to build stuff with --disable-year2038 and maybe
even with --disable-largefile, and when that bombs out I want it to be
crystal clear from the text of configure.ac that it bombed out because
package X considers 64-bit time_t and/or off_t a requirement.

Please revert that part of your follow-up patch.

> * The documentation incorrectly implies that AC_SYS_LARGEFILE and
> AC_SYS_YEAR2038 are orthogonal, i.e., that one can request large-file
> support and year-2038 support independently. But AC_SYS_YEAR2038
> AC_REQUIREs AC_SYS_LARGEFILE, and one cannot configure with
> --disable-largefile --enable-year2038 and expect things to work. This
> is inherent to the underlying _TIME_BITS mechanism; it's not something
> Autoconf can fix with glibc

I *intended* to make it clear that they are not orthogonal in
practice, but it is not logically necessary for them to be coupled,
and it is, I think, easier to understand what
AC_SYS_{LARGEFILE,YEAR2038} do if we document them as abstractly
orthogonal but then explain that on all the systems where
--enable-year2038 currently does something, it implies
--enable-largefile.

Your changes to the manual are hard for me to read.  Is there any
chance you could send a wdiff to the list, after restoring the text
you took out because you took out the _REQUIRED variants?

In the new year, I can look into the possibility of decoupling the
macros’ implementations.

> +*** AC_SYS_LARGEFILE now optionally arranges to widen time_t.
> +  It now causes 'configure' to gain an --enable-year2038 option which
> +  widens time_t if possible on systems where time_t by default cannot
> +  represent file timestamps and other timestamps after January 2038.
> +  As with off_t, ino_t, etc., if library ABIs depend on time_t width,
> +  applications should be configured consistently with libraries.
> +
> +*** New macro AC_SYS_YEAR2038.
> +  This acts like AC_SYS_LARGEFILE, except that it causes 'configure'
> +  to default to --enable-year2038.  In a future Autoconf version,
> +  AC_SYS_LARGEFILE is planned to do this too, so the two macros will
> +  become equivalent.

I think you’re still writing documentation with application-colored
glasses on, making it sound like --enable-year2038 has no negative
implications whatsoever.  Moreover, I do not believe we have consensus
for AC_SYS_LARGEFILE to become a synonym for AC_SYS_YEAR2038, not even
“in a future Autoconf version.”

Please revert NEWS to my text as well, except for this paragraph

> -  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.

which, on reflection, doesn’t need to be in NEWS, and add this

  Enlarging time_t to 64 bits is likely to have the side effect of
  enlarging off_t and related types to 64 bits as well, as if you
  had used AC_SYS_LARGEFILE.  See the manual for details.

to the section on AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.

zw