Re: (format "%c" ... ) sometimes returns multibyte chars when unibyte expected (?)

[Kenichi Handa]

In article <address@hidden>, Nils Klarlund <address@hidden> writes:
> In order to format a positive integer as a string (of four bytes), one
> might expect to use the "format" function.  At least, this is what is
> done presently in vr-mode (that connects Emacs to NaturallySpeaking)
> [the function is enclosed below, not that it is really important). 

> But the behavior of "format" seems erroneous or at least
> unpredictable.  For example, sometimes 169 becomes a unibyte,
> sometimes a multiplebyte character (using the very latest cvs version
> I could check out):

>   (aref (format "%c" 169) 0) --> 169
>   (aref (format "%c%c" 0 169) 1) --> 2217

In general, if all the character arguements are ascii,
eight-bit-control, or eight-bit-graphic, format returns a
unibyte string.  Otherwise, it returns a multibyte string
while converting eight-bit-graphic/control characters to the
corresponding multibyte character codes).

But, the character code 0 is special in
format and no one remember why it is so (see this comment in
Fformat of editfns.c) :-(

            if (*format == 'c')
              {
                if (! SINGLE_BYTE_CHAR_P (XINT (args[n]))
                    /* Note: No one can remember why we have to treat
                       the character 0 as a multibyte character here.
                       But, until it causes a real problem, let's
                       don't change it.  */
                    || XINT (args[n]) == 0)

Anyway, 

> (defun vr-etonl (i)
>   (format "%c%c%c%c"
>         (lsh (logand i 4278190080) -24)
>         (lsh (logand i 16711680) -16)
>         (lsh (logand i 65280) -8)
>         (logand i 255)))

I think you can use the function string as below in this
case (and it is faster):

(defun vr-etonl (i)
  (string (lsh (logand i 4278190080) -24)
          (lsh (logand i 16711680) -16)
          (lsh (logand i 65280) -8)
          (logand i 255)))

---
Ken'ichi HANDA
address@hidden