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

[Eli Zaretskii <eliz@gnu.org>]

> From: handa@gnu.org (K. Handa)
> Cc: dmantipov@yandex.ru, maden.ldm@gmail.com, 18610@debbugs.gnu.org
> Date: Mon, 06 Oct 2014 23:00:10 +0900
> 
> In article <83zjdamrbd.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > No.  Even if there's no special ISO-2022 escape sequence, we
> > > should not reject iso-2022 as a detected coding system.
> 
> > Can you explain why?  AFAICT, all the other detectors are required to
> > set some flag in the 'found' field, so why is ISO-2022 special in this
> > regard?
> 
> Because the file contains the byte #x96 which is included in
> latin-extra-code-table (i.e. (aref latin-extra-code-table
> #x96) is t).

Yes, but what's the reason for having latin-extra-code-table in the
first place?

> > Btw, it would be nice if these masks could be documented so that their
> > meaning was clear.  I considered the possibility that the flags are
> > not set correctly, but couldn't test that hypothesis given my
> > insufficient knowledge of ISO-2022 details and variants.
> 
> Sorry for the poor comments in my code.  I'll work on it soon.

TIA.

> > would set the buffer-file-coding-system of the buffer
> > visiting the file to 'undecided', and regarded the \226
> > characters as 8-bit raw bytes:
> 
> I think that is a bug.  If the file doesn't contain ESC, it
> is detected as latin-1.  If the file contains latin-1 byte
> 0xA0..0xFF instead of \226, it is detected as latin-1.  So,
> as far as \226 is treated as extra latin code, it should be
> decoded as latin-1.

OK.  Do you think this fix is safe enough to go to the release branch,
so as to prevent Emacs 24.4 from crashing in these circumstances?