emacs-pretest-bug
[Top][All Lists]
Advanced

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

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


From: Nils Klarlund
Subject: Re: (format "%c" ... ) sometimes returns multibyte chars when unibyte expected (?)
Date: Mon, 23 Aug 2004 08:23:12 -0400
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

Thanks for the clarification. This convention about 0 must be recent I guess. In Emacs 21.3
"GNU Emacs 21.3.1 (i386-mingw-nt5.1.2600)  of 2004-03-10 on NYAUMO"

 (aref (format "%c%c" 0 169) 1)

does in fact evaluate to 169. Anyway, I appreciate the hint about just using "string"; I will pass it
on to the maintainer.

/Nils

Kenichi Handa wrote:

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





reply via email to

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