bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: K. Handa
Subject: bug#18610: 24.4.50; Specific file causing emacs to segfault upon opening
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).

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

> > I've just installed a fix to trunk.  Could you please try
> > the latest version?

> It fixes the crash, but I'm not sure the results are what we want.
> Emacs 24.3, which also did not crash,

24.3 had this bug too but it doesn't utilize
coding->head_ascii in the current case.  After 24.3, I
changed the code to utilize coding->head_ascii more for
optimization.

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

---
Kenichi Handa
handa@gnu.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]