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

[Jim Meyering]

On Mon, Apr 3, 2023 at 11:20 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> 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?

I followed that autoconf discussion and am all for requiring y2038
support in the tools we tend.