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

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Tue, 07 Oct 2014 15:10:52 +0000
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> >>>>> From: Ivan Shmakov Date: Tue, 07 Oct 2014 13:20:03 +0000
> 
>  >>>> Yes, but what's the reason for having latin-extra-code-table in
>  >>>> the first place?
> 
>  >>> I vaguely remember that it was a request from latin-1 users who
>  >>> occasionally have to edit files created by Windows users, and those
>  >>> files tend to contain those non-Latin-1 characters.
> 
> […]
> 
>  >> Thus, just using the windows-1252 encoding (perhaps also as a
>  >> default fallback in Latin-1 environments) looks like a cleaner
>  >> solution to me.
> 
>  > Solution to what problem?
> 
>       To the problem of reading “files created by Windows users” into
>       Emacs buffers.  (See above.)

But that's not the issue discussed in this bug report, not at all.
(And we don't know whether the file was created by a Windows user;
most probably it wasn't, because it looks like a binary file to me.)

>  > And how do you propose to apply that solution in the case in point,
> 
>       By a chance, aren’t we now talking about different issues
>       altogether?  (Emacs crashing vs. latin-extra-code-table.)

latin-extra-code-table was mentioned because it is relevant to the
code in question, the one that detects ISO-2022 encoding variants.

>  > where Emacs is _guessing_ the encoding, as the user didn't tell how
>  > to decode the file?
> 
>       Sorry, I don’t know the exact magic Emacs implements in this
>       case, but couldn’t Emacs be instructed to, whenever
>       (set-language-environment "Latin-1") is in effect, try to use
>       the windows-1252 encoding for the files being read /iff/
>       iso-8859-1 (the default in this case, I presume) fails?

Maybe, but that's not what users on Unix want IME.  And no, Latin-1
didn't fail in this case; in fact, it wasn't even tried.