emacs-devel
[Top][All Lists]
Advanced

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

Re: Coding system conversion error


From: Kim F. Storm
Subject: Re: Coding system conversion error
Date: Sat, 12 Feb 2005 15:34:52 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Jan D." <address@hidden> writes:

>> At first, I think xassert in lisp_data_to_selection_data
>> (xselect.c) is wrong.  Here, obj is generated by a Lisp code
>> that may generate a multibyte string by error (as in the
>> current case).  But, in general, an error in Lisp code
>> should not lead to abort.  So, I propose this change.  I
>> choose string_make_unibyte instead of string_as_unibyte to
>> avoid exporting Emacs' internal leading bytes.
>>
>> *** xselect.c        12 Feb 2005 09:54:46 +0900      1.148
>> --- xselect.c        12 Feb 2005 10:39:47 +0900      
>> ***************
>> *** 1908,1914 ****
>>       }
>>     else if (STRINGP (obj))
>>       {
>> !       xassert (! STRING_MULTIBYTE (obj));
>>         if (NILP (type))
>>      type = QSTRING;
>>         *format_ret = 8;
>> --- 1908,1915 ----
>>       }
>>     else if (STRINGP (obj))
>>       {
>> !       if (STRING_MULTIBYTE (obj))
>> !    obj = string_make_unibyte (obj);
>>         if (NILP (type))
>>      type = QSTRING;
>>         *format_ret = 8;
>
> If the multibyte string is generated by an error and this is one of
> the places where we can detect the error, should we not keep the
> xassert?

I agree, but since the source of the error is in Lisp code, it would
be more helpful to signal an error rather than abort.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk





reply via email to

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