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

Previous Next

Full log

Message #16 received at 62647 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 62647 <at> debbugs.gnu.org
Subject: Re: 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 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.