Re: (insert 8000) crashes XEmacs 21.2.16
Veto.
When I wrote all this code, I made a conscious decision, for compatibility
reasons, to allow integers wherever characters are allowed. If we're going to
change this, (a) we should think carefully about what this means, and (b) we
should fix this all throughout XEmacs.
The bug you're seeing looks to actually be a bug in CHAR_INTP(), which is
supposed to recognize valid character integers. Therefore, you should fix
this macro.
ben
Yoshiki Hayashi wrote:
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp>
writes:
> >>>>> "Kyle" == Kyle Jones
<kyle_jones(a)wonderworks.com> writes:
>
> Kyle> (insert 8000) seems fundamentally broken to me. [...]
>
> Kyle> I think Finsert ought to be made to signal
> Kyle> wrong-type-argument when handed an integer.
>
> Agree.
>
> In Mule characters must be opaque objects---currently they have
> internal structure, and internal representation is under consideration
> for revision. FSFmacs has the appropriate character-creation
> functions because it uses the same representation; code that doesn't
> use them is broken in both variants.
OK. Here is the patch. With this patch, Finsert will be OK,
but you can still make XEmacs crash with (int-to-char 8000).
I'll write fix for that later.
When this patch is applied, w3 must be fixed since it uses
(insert INT) to insert Ϩ or something like that.
1999-11-09 Yoshiki Hayashi <t90553(a)mail.ecc.u-tokyo.ac.jp>
* editfns.c (buffer_insert_1): Don't treat an integer as
a character.
------------------------------------------------------------------------
Name: editfns.c.diff
editfns.c.diff Type: Plain Text (text/plain)
Encoding: 7bit
------------------------------------------------------------------------
--
Yoshiki Hayashi