On 2023-04-03 10:52, Jim Meyering wrote:
I wanted to see how this would make grep fail, but don't
have convenient access to such hosts. Would this trigger the failure?
touch -t 203901010000 f
grep ^ f
Yes, that triggers it. Of course one needs a "touch" and a filesystem
that supports such timestamps.
Come to think of it, the year2038 module (which coreutils also employs)
no longer defaults to requiring year2038 support like it used to. It now
merely enables year2038 support if available. Should we change this in
Gnulib? This would affect coreutils, grep etc.
Gnulib year2038 became milder when there was pushback about
AC_SYS_YEAR2038 when it got added to Autoconf. The next Autoconf will
have AC_SYS_YEAR2038 (which merely tries to get Y2038 support) and
AC_SYS_YEAR2038_REQUIRED (which requires it).
It's a controversial area because these two modules can change library
ABIs. I suppose in theory we could add Gnulib modules largefile-required
and year2038-required, and have coreutils, grep, etc. use these modules.
However, this doesn't seem worth the hassle, since packages using the
largefile and year2038 modules are typically compiled with their default
options. So I'm sort of leaning toward modifying Gnulib's largefile and
year2038 modules to use the _REQUIRED variants.
Thoughts?
How does it fail?
It outputs "grep: f: Value too large for defined data type" to stderr
with exit status 2.
I reproduced the problem by configuring bleeding-edge grep on Ubuntu
22.10 x86-64 with an i686 compiler and library installed, and
configuring this way:
./configure CC='gcc -m32' --disable-year2038
