[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86, ARM
Date: Mon, 3 Apr 2023 11:20:23 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]