On Mon, Apr 3, 2023 at 11:20 AM Paul Eggert <egg...@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.
