Re: emacs-25 b6b47AF: Properly encode/decode base64Binary data in SOAP

[Eli Zaretskii]

> From: Thomas Fitzsimmons <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden,  address@hidden
> Date: Tue, 15 Mar 2016 10:39:02 -0400
> 
> I think Andreas explained it with his code snippet.  IIUC, async does a
> `read' on the sexp from the child process, and read returns a unibyte
> string if there are no non-ASCII characters in the string.  If there are
> non-ASCII characters, then read returns a multibyte string:
> 
> (let ((pair (read "(\"á\" \"a\")")))
>   (list (multibyte-string-p (car pair))
>       (multibyte-string-p (cdr pair))))
> => (t nil)

Yes.

> I don't think this will affect debbugs.el's functionality though, since
> it will always decode fields that it knows might contain non-ASCII.

Decoding a pure-ASCII string is harmless.

> The only difference will be that ASCII-only strings coming back from
> debbugs-over-async will be unibyte, whereas ASCII-only strings coming
> back from in-process debbugs.el will be multibyte, because:
> 
> (multibyte-string-p
>  (async-get (async-start
>            `(lambda ()
>               (decode-coding-string "a" 'utf-8)))))
> => nil
> 
> (multibyte-string-p (decode-coding-string "a" 'utf-8))
> => t
> 
> As long as no users of the debbugs.el APIs key off multibytedness of the
> strings, they'll be fine.  I guess this is a quirk of async, that it
> strips the multibytedness of strings that are multibyte-ASCII-only in
> the inferior.

I don't think it's something async does, nor is it a quirk.  Depending
on the APIs used, Emacs might decide to produce a unibyte string if
the text is pure ASCII.  That is harmless and should never cause any
problems.

Thanks.