[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: Jim Meyering
Subject: bug#62647: [INSTALL] grep: re-fix Y2038 bug on glibc 2.34+ x86, ARM
Date: Mon, 3 Apr 2023 19:49:23 -0700

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.

reply via email to

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