1
0
mirror of https://git.savannah.gnu.org/git/emacs.git synced 2024-12-15 09:47:20 +00:00

More backward-compatible fix to char-equal core dump.

* editfns.c (Fchar_equal): In unibyte buffers, assume values in
range 128-255 are raw bytes.  Suggested by Eli Zaretskii.

Fixes: debbugs:17011
This commit is contained in:
Paul Eggert 2014-03-26 10:55:31 -07:00
parent 196716cf35
commit 3fd3e73693
2 changed files with 20 additions and 6 deletions

View File

@ -1,4 +1,8 @@
2014-03-26 Paul Eggert <eggert@cs.ucla.edu>
2014-03-26 Paul Eggert <eggert@penguin.cs.ucla.edu>
More backward-compatible fix to char-equal core dump (Bug#17011).
* editfns.c (Fchar_equal): In unibyte buffers, assume values in
range 128-255 are raw bytes. Suggested by Eli Zaretskii.
Fix core dump in char-equal (Bug#17011).
* editfns.c (Fchar_equal): Do not use MAKE_CHAR_MULTIBYTE in

View File

@ -4377,13 +4377,23 @@ Case is ignored if `case-fold-search' is non-nil in the current buffer. */)
if (NILP (BVAR (current_buffer, case_fold_search)))
return Qnil;
/* FIXME: When enable-multibyte-characters is nil, it's still possible
to manipulate multibyte chars, which means there is a bug for chars
in the range 128-255 as we can't tell whether they are eight-bit
bytes or Latin-1 chars. For now, assume the latter. See Bug#17011.
Also see casefiddle.c's casify_object, which has a similar problem. */
i1 = XFASTINT (c1);
i2 = XFASTINT (c2);
/* FIXME: It is possible to compare multibyte characters even when
the current buffer is unibyte. Unfortunately this is ambiguous
for characters between 128 and 255, as they could be either
eight-bit raw bytes or Latin-1 characters. Assume the former for
now. See Bug#17011, and also see casefiddle.c's casify_object,
which has a similar problem. */
if (NILP (BVAR (current_buffer, enable_multibyte_characters)))
{
if (SINGLE_BYTE_CHAR_P (i1))
i1 = UNIBYTE_TO_CHAR (i1);
if (SINGLE_BYTE_CHAR_P (i2))
i2 = UNIBYTE_TO_CHAR (i2);
}
return (downcase (i1) == downcase (i2) ? Qt : Qnil);
}