GNU bug report logs - #43597
28.0.50; arc-mode.el fails to display a ZIP file

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Thu, 24 Sep 2020 20:04:02 UTC

Severity: normal

Found in version 28.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43597 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: bug#43597: 28.0.50; arc-mode.el fails to display a ZIP file
Date: Fri, 25 Sep 2020 09:13:42 +0200
On Fri, 25 Sep 2020 09:01:02 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Thu, 24 Sep 2020 22:40:15 +0200
>> Cc: 43597 <at> debbugs.gnu.org
>>
>>   (let ((p (archive-l-e (+ (point) 16) 4))
>>         files)
>>     (when (= p -1)
>>       ;; If the offset of end-of-central-directory is -1, this is a
>>       ;; Zip64 extended ZIP file format, and we need to glean the info
>>       ;; from Zip64 records instead.
>>
>> But the first value returned by archive-l-e for this file is 255, not
>> -1, and on each iteration the value increases, so the ZIP64 code in the
>> body of the when-clause is never executed.
>
> This code worked when support for ZIP64 was added.
>
> Could it be that the problem is in archive-l-e?  Something related to
> bignums, perhaps?

According to NEWS bignum support was added in Emacs 27, so I just made a
fresh build from the Emacs 26 branch and get the same failure.

>                    Why does it return 255 instead of -1 in this case?

Here's what happens (in Emacs 26 as well as 27 and master, though the
code changed slightly due, I assume to the introduction of bignums):
archive-l-e loops through the string "\377\377\377\377", each time
adding the decimal value of the byte to the value after shifting left by
8 bits.  Since octal 377 is decimal 255, the result of each iteration is
the following: 255, 65535, 16777215, 4294967295.  The last value is what
is returned to archive-zip-summarize.  Is it supposed to return -1 due
to overflowing or something?  In any case, the same thing happens in
Emacs 26, 27 and master, so it seems whatever changed the return value
happened earlier.

Steve Berman




This bug report was last modified 4 years and 299 days ago.

Previous Next


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