Re: Compiling Elisp to a native code with a GCC plugin

[David Kastrup]

Lars Magne Ingebrigtsen <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> In this case, the byte patterns can be the same and the texts still
>> different, and vice versa.
>
> So just to be clear here, you think this is correct:
>
> (equalp (unibyte-string #x68 #xe9 #x6c #x6c #x6f) "héllo")
> => nil

equalp does not exist.  I'll change to equal for the rest of the
discussion.

> But that this behaviour is incorrect?
>
> (equal (unibyte-string #x68 #x6c #x6c #x6f) "hllo")
> => t

No.  Correct.

> But that this is correct:
>
> (equal (unibyte-string #x68 #xc3 #xa9 #x6c #x6c #x6f) "héllo")
> => nil

Still correct.  But notice that
(equal
   (string-as-multibyte (unibyte-string #x68 #xc3 #xa9 #x6c #x6c #x6f)) "héllo")
=> t

And notice

(equal (unibyte-string #x68 #xe9 #x6c #x6c #x6f) "h\351llo")
=> t
whereas (equal "h\351llo" "héllo") => nil
while (equal "h\u00e9llo" "héllo") => t

It should probably be called an error that the print form of "h\351llo"
is "héllo" on an utf-8 terminal.  That does not particularly help to
make things less confusing since the input forms are non-equivalent.

-- 
David Kastrup