Subject: bug#43597: closed (Re: bug#43597: 28.0.50; arc-mode.el fails to display a ZIP file)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 25 Sep 2020 14:13:02 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
43597: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43597
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#43597: 28.0.50; arc-mode.el fails to display a ZIP file
From: Eli Zaretskii <[email-masked]>
To: Stephen Berman <[email-masked]>
Cc: [email-masked]
Date: Fri, 25 Sep 2020 17:12:42 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Stephen Berman <[email-masked]>
> Cc: [email-masked]
> Date: Fri, 25 Sep 2020 15:58:36 +0200
> 
> > Anyway, here's the proposed patch, please test:
> 
> It works for me (at first I applied it to master and the patch partly
> failed to apply, then I looked at the line numbers and realized it was
> for Emacs 27).  Thanks.

Thanks, installed on the emacs-27 branch, and closing the bug.

Subject: 28.0.50; arc-mode.el fails to display a ZIP file
From: Stephen Berman <[email-masked]>
To: [email-masked]
Date: Thu, 24 Sep 2020 22:02:50 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

I have a ZIP file that, when I try to visit it in archive-mode, Emacs
throws a file mode specification error on, specifically
args-out-of-range.  The reason is that the function archive-l-e in
arc-mode.el, which is supposed to return a buffer position in this case,
returns a number which exceeds the buffer size.  And the reason for this
is that archive-l-e builds its return value by iteratively calling (+
(ash result 8) (aref str (- len i))), where `str' is a string extracted
from the end of the ZIP file, which in this case is "\377\377\377\377",
so that the return value increases from 255 (the decimal value of octal
377) to 4294967040 after four iterations, which far exceeds the file
(and hence buffer) size.

Perhaps "\377\377\377\377" is an invalid string at the end of a ZIP file
(I checked other ZIP files I have, which I can visit in archive-mode
with no problem, and they have different strings at the end, consisting
of bytes with smaller decimal values, so that the return value of
archive-l-e does not exceed the file size).  Yet when I call `unzip -l'
on the file in the shell, the contents are displayed, and I also had no
problem unpacking the file with unzip (and AFAICT the content is
undamaged).  So at least unzip can deal with this file.

In case it helps, here is the final byte sequence in the file (I've
replace the control characters and raw bytes by ASCII representations):

PK^E^F\377\377\377\377%^@%^@\377\377\377\377\377\377\377\377^@^@

In GNU Emacs 28.0.50 (build 25, x86_64-pc-linux-gnu, GTK+ Version 3.24.17, cairo version 1.17.3)
 of 2020-09-24 built on strobe-jhalfs
Repository revision: 89dd8cd215148da4c6dffc15dc6c35df5122247b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Linux From Scratch SVN-20200401

Configured using:
 'configure 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD PDUMPER LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix