Re: Coding system conversion error

[Kenichi Handa]

Sorry for the late response on this thread.

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;


In article <address@hidden>, "Jan D." <address@hidden> writes:

> ELISP>  (setq str (string-to-multibyte <1025 ASCII character string>))
> ...
> ELISP>  (multibyte-string-p str)
> t
> ELISP>  (multibyte-string-p (encode-coding-string str
>                                               
> 'compound-text-with-extensions))
> t     <---- BUG, should be nil
> ELISP>  (multibyte-string-p (encode-coding-string str 'utf-8))
> nil

Thank you for finding this bug.  As encode-coding-string
should be regarded as an interface between multibyte and
unibyte, it should always return an unibyte string.  But,
NOCOPY argument in encode-coding-string and
encode_coding_string is to avoid unnecessary string
allocation if STR is ASCII-only.  So, in such a case, I'm
going to change that function to modify STR to unibyte
directly (i.e. by calling STRING_SET_UNIBYTE) instead of
calling Fstring_as_unibyte.

What do you think?

---
Ken'ichi HANDA
address@hidden