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

[Stephen Berman]

On Fri, 25 Sep 2020 09:01:02 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Thu, 24 Sep 2020 22:40:15 +0200
>> Cc: 43597@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