bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening

[K. Handa]

In article <83a95dibtt.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > The whole thing is really subtle: when detect_coding is called, it finds 
> > (1) and
> > calls to detect_coding_iso_2022, which returns 1.  Since this happens before
> > detect_coding finds (2), this function assumes that the whole data is in 
> > one of
> > 7-bit (?) ISO-2022 encoding.  Thus, no conversion is performed, and 
> > decode_coding_gap
> > inserts the data as is; this way we end up with 96 3B byte sequence in 
> > buffer text.

> Indeed.  But I don't think we can simply reject ISO-2022 here, because
> the mere presence of bytes in [128..159] is not supposed to reject the
> possibility of decoding that text by ISO-2022, see
> latin-extra-code-table.

> However, detect_coding_iso_2022 returns with the 'found' member of its
> second argument having zero value, which I interpret as meaning that
> it didn't really find any ISO-2022 sequences.  So the simple patch
> below fixes this for me.  Kenichi, is this patch OK?

No.  Even if there's no special ISO-2022 escape sequence, we
should not reject iso-2022 as a detected coding system.
And, even if that detection was incorrect, the decoder
should not produce an invalid byte sequence in a
buffer/string which leads to Emacs crash.

The bug is in detect_coding_iso_2022 which doesn't set
CATEGORY_MASK_ISO_7_ELSE in coding->rejected in this case.
Because of that, coding->head_ascii is incorrectly set.

I've just installed a fix to trunk.  Could you please try
the latest version?

---
Kenichi Handa
handa@gnu.org