Re: AC_SYS_LARGEFILE_REQUIRED vs. AC_SYS_YEAR2038_REQUIRED on MSVC

[Bruno Haible]

I presented the test results:
>   - hello-3: no gnulib, just AC_SYS_LARGEFILE_REQUIRED
>   - hello-4: no gnulib, just AC_SYS_YEAR2038_REQUIRED
>   - testdir3: a gnulib testdir for the modules largefile-required stat
>   - testdir4: a gnulib testdir for the modules year2038-required stat
> 
>              mingw64  mingw32  msvc64  msvc32
> 
> hello-3        OK       OK     "support not detected" -> fail
> hello-4        OK       OK     "support not detected" -> fail
> testdir3       OK       OK       OK      OK
> testdir4       OK       OK       OK      OK

Now, one could argue that in the above table the outcome should be:

             mingw64  mingw32  msvc64  msvc32

hello-3        OK       OK     "support not detected" -> fail
hello-4        OK       OK       OK      OK
testdir3       OK       OK       OK      OK
testdir4       OK       OK       OK      OK

since in hello-4 the maintainer has only asked for year 2038
support, not for large files support. And the dependency from year 2038
support to large files support exists only in glibc (since the glibc
developers found it pointless to add a 'struct stat' variant with
32-bit off_t and 64-bit time_t). Whereas MSVC has all 4 possible
variants for 'struct stat' (32/64-bit off_t and 32/64-bit time_t) [1].

But for this improvement, the Autoconf code of AC_SYS_YEAR2038_REQUIRED
would need to distinguish glibc systems from MSVC systems in one way or
the other. You said that you don't like the use AC_CANONICAL_HOST here;
on the other hand, an extra compiler or preprocessor invocation is
pointless if AC_CANONICAL_HOST has already been used.

Anyway, this is low priority for me, since MSVC support without gnulib
is not going to work well in so many aspects anyway.

Bruno

[1] 
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=msvc-170