GNU bug report logs - #29033
new snapshot available: gzip-1.8.32-4606

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>, Jim Meyering <jim <at> meyering.net>
Cc: 29033 <at> debbugs.gnu.org, Gnulib bugs <bug-gnulib <at> gnu.org>
Subject: Re: bug#29033: [platform-testers] new snapshot available:
 gzip-1.8.32-4606
Date: Mon, 6 Nov 2017 23:29:01 -0800

[Message part 1 (text/plain, inline)]

Bruno Haible wrote:

> + touch -t 210602070628.15 in
> touch: invalid date format '210602070628.15'
> + printf '\037\213\10\0\377\377\377\377\0\377\3\0\0\0\0\0\0\0\0\0'
> + returns_ 2 gzip -Nlv
> method  crc     date  time           compressed        uncompressed  ratio uncompressed_name
> defla 00000000 Oct 28 00:47                  20                   0   0.0% stdout
> + fail=1

Instead of suppressing the test, how about if we tell builders not to build with 
-m32 on platforms supporting 64-bit time_t? That way, they won't run into a 
problem where gzip mishandles file timestamps due to OS screwups or 
errno==EOVERFLOW problems that cannot happen with 64-bit time_t. In the 
not-too-distant future we're going to have to insist on 64-bit time_t anyway, 
and in the meantime we can strongly suggest 64-bit time_t by installing the 
first attached patch to gzip (which I've done), by installing the attached 
proposed patch to Gnulib (which I have not done yet, pending your comments), and 
by syncing gzip to gnulib.

> I think the problem is this comment:
> # On platforms that fail to support timestamps within gzip's range,
> # test that gzip warns when converting them from gzip format.
> 
> Gzip's behaviour depends on libc, and what the 'touch' program is doing
> is a different thing. It's incorrect to assume that libc's behaviour and
> touch's behaviour are consistent.

The testcase doesn't assume that. It merely assumes that standard utilities 
support a superset of the timestamps that libc supports. This should be a 
reasonable assumption for the -m32 case that you describe (and which I'm trying 
to discourage with the abovementioned patches).

The assumption would not be reasonable for platforms where standard utilities 
are worse than libc, but this should be uncommon. If it is a problem, perhaps we 
can get by, by simply telling users to ignore the tests in that case.

CC'ing to bug-gnulib since the 2nd patch is for Gnulib.

[0001-misc-diagnose-year-2038-configuration-problems.patch (text/x-patch, attachment)]

[0001-year2038-be-more-insistent-about-64-bit-time_t.patch (text/x-patch, attachment)]

Previous Next

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