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

[Eli Zaretskii]

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