bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86, ARM

[Paul Eggert]

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