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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 03 Oct 2014 15:22:12 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Eli Zaretskii <eliz@gnu.org>, 18610@debbugs.gnu.org, 
>  maden.ldm@gmail.com
> 
> There is a reduced sample which is just 194 bytes (attached).

Thanks, I also arrived at such a shortened version.

But the shortest version is just this:

1B 96

IOW, you need an escape and a raw byte between 128 and 159
(inclusive).

> 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?

=== modified file 'src/coding.c'
--- src/coding.c	2014-08-06 17:37:22 +0000
+++ src/coding.c	2014-10-03 12:09:28 +0000
@@ -6559,7 +6559,8 @@ detect_coding (struct coding_system *cod
 		  && ! inhibit_ied
 		  && ! detect_info.checked)
 		{
-		  if (detect_coding_iso_2022 (coding, &detect_info))
+		  if (detect_coding_iso_2022 (coding, &detect_info)
+		      && detect_info.found != 0)
 		    {
 		      /* We have scanned the whole data.  */
 		      if (! (detect_info.rejected & CATEGORY_MASK_ISO_7_ELSE))