From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-25 b6b47AF: Properly encode/decode base64Binary data in SOAP Date: Tue, 15 Mar 2016 19:39:04 +0200 Message-ID: <83k2l3bpzb.fsf@gnu.org> References: <20160106200404.17375.71733@vcs.savannah.gnu.org> <87d1r1x84z.fsf@linux-m68k.org> <83lh5mfjsn.fsf@gnu.org> <83oaaidydx.fsf@gnu.org> <83io0qdtb0.fsf@gnu.org> <83egbdenx4.fsf@gnu.org> <87fuvtqv33.fsf@gmx.de> <87d1qx9qv7.fsf@gmx.de> <87a8m1cfmt.fsf@gmx.de> <83h9g9c566.fsf@gnu.org> <87twk8i2nv.fsf@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1458063617 12217 80.91.229.3 (15 Mar 2016 17:40:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Mar 2016 17:40:17 +0000 (UTC) Cc: michael.albinus@gmx.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Thomas Fitzsimmons Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 15 18:40:15 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1afsx3-0006Uj-Uc for ged-emacs-devel@m.gmane.org; Tue, 15 Mar 2016 18:40:14 +0100 Original-Received: from localhost ([::1]:50311 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afsx3-0006LF-8L for ged-emacs-devel@m.gmane.org; Tue, 15 Mar 2016 13:40:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afswP-0005jF-49 for emacs-devel@gnu.org; Tue, 15 Mar 2016 13:39:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afswL-0005Nt-NH for emacs-devel@gnu.org; Tue, 15 Mar 2016 13:39:33 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afswL-0005Nl-K0; Tue, 15 Mar 2016 13:39:29 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3972 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1afswK-0003kB-A2; Tue, 15 Mar 2016 13:39:28 -0400 In-reply-to: (message from Thomas Fitzsimmons on Tue, 15 Mar 2016 10:39:02 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201785 Archived-At: > From: Thomas Fitzsimmons > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org > 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.