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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 03 Oct 2014 15:20:46 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18610@debbugs.gnu.org, maden.ldm@gmail.com
> 
> --- 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))
> 
> 

Alternatively, perhaps detect_coding_iso_2022 shouldn't return 1 if
the 'found' member is zero.

Btw, there's one more issue that bothers me.  In ONE_MORE_BYTE we have
this:

    c = *src++;						\
    if (multibytep && (c & 0x80))			\
      {							\
	if ((c & 0xFE) == 0xC0)				\
	  c = ((c & 1) << 6) | *src++;			\
	else						\
	  {						\
	    src--;					\
	    c = - string_char (src, &src, NULL);	\
	    record_conversion_result			\
	      (coding, CODING_RESULT_INVALID_SRC);	\
	  }						\
      }							\

If 'src' is a signed type, the first line above assigns a negative
value to c for values beyond 127.  But, as seen from the code after
that, negative values have special meaning.  So I wonder if we need to
make sure the first line above always assigns non-negative values to
c.

Same problem exists in TWO_MORE_BYTES.