From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bug#23750: 25.0.95; bug in url-retrieve or json.el Date: Wed, 28 Dec 2016 20:27:48 +0200 Message-ID: <83mvffvrh7.fsf@gnu.org> References: <6d0c8c2e-8428-2fdb-0d6e-899f7b9d7ffd@nifty.com> <8053af81-80e1-a24a-f649-8ffc86963ed5@nifty.com> <0cc7fab4-9a2c-6a8d-def7-36bd50317ca3@yandex.ru> <7f9a799f-de88-fd78-0cdc-dac0928f1503@nifty.com> <308bb78f-8be3-092d-d877-e129d340242b@nifty.com> <4dc615e7-ec73-60a5-426e-0d6986f15d76@yandex.ru> <0cb406fb-ffc4-a4ad-557a-2cacc99b8e75@nifty.com> <86ccb4af-5719-c017-26bb-fc06b4c904d2@yandex.ru> <83r35uxkr5.fsf@gnu.org> <4e12d4ad-cd6b-3087-5d7c-449d4c1886e2@yandex.ru> <83lgw1q9uu.fsf@gnu.org> <83eg1tq8is.fsf@gnu.org> <787e5206-53e0-752f-a339-4608d2f7ad39@yandex.ru> <8360n5q6j4.fsf@gnu.org> <83r35sq02k.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1482949732 21308 195.159.176.226 (28 Dec 2016 18:28:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Dec 2016 18:28:52 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org, kentaro.nakazawa@nifty.com, dgutov@yandex.ru To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 28 19:28:48 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cMIxn-0003IM-Qa for ged-emacs-devel@m.gmane.org; Wed, 28 Dec 2016 19:28:35 +0100 Original-Received: from localhost ([::1]:60427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMIxp-00017F-Pa for ged-emacs-devel@m.gmane.org; Wed, 28 Dec 2016 13:28:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMIxE-00017A-HS for emacs-devel@gnu.org; Wed, 28 Dec 2016 13:28:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cMIxA-0005Xr-Jv for emacs-devel@gnu.org; Wed, 28 Dec 2016 13:28:00 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cMIxA-0005Xn-HF; Wed, 28 Dec 2016 13:27:56 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4229 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cMIx9-00035l-M1; Wed, 28 Dec 2016 13:27:56 -0500 In-reply-to: (message from Philipp Stephani on Wed, 28 Dec 2016 18:09:52 +0000) 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.21 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" Xref: news.gmane.org gmane.emacs.devel:210920 Archived-At: > From: Philipp Stephani > Date: Wed, 28 Dec 2016 18:09:52 +0000 > Cc: larsi@gnus.org, dgutov@yandex.ru, kentaro.nakazawa@nifty.com, > emacs-devel@gnu.org > > > [1:text/plain Show] > > > [2:text/html Hide Save:noname (9kB)] > > Eli Zaretskii schrieb am Mi., 30. Nov. 2016 um 19:45 Uhr: > > > From: Philipp Stephani > > Date: Wed, 30 Nov 2016 18:23:14 +0000 > > Cc: dgutov@yandex.ru, kentaro.nakazawa@nifty.com, emacs-devel@gnu.org > > > > > Yes, this is not a json.el problem at all. It does the correct thing, > > > and shouldn't be changed. > > > > ??? Why should any code care whether a pure-ASCII string is marked as > > unibyte or as multibyte? Both are "correct". > > > > I guess the problem is that process-send-string cares. If it didn't, we wouldn't have the problem. > > I don't think I follow. The error we are talking about is signaled > from url-http-create-request, not from process-send-string. > > Yes, but url-http-create-request only cares about unibyte strings because the request it creates is passed to > process-send-string, which special-cases unibyte strings. How do you see that process-send-string special-cases unibyte strings? > > For URL, we'd need functions like > > (byte-array-length s) = (length (string-to-unibyte s)) > > Why do you need this? string-to-unibyte is well-defined only for > unibyte or ASCII strings (if we forget the raw bytes for a moment), so > length will do. > > We need it because we have to send the byte length in a header. We can't just use (length s) because it > would silently give a wrong result. We are miscommunicating. string-to-unibyte can only meaningfully be called on a pure-ASCII string, and for pure-ASCII strings 'length' will count bytes. So I see no need for 'byte-array-length' if its implementation is as you indicated. > > (process-send-bytes s) = (process-send-string (string-to-unibyte s)) > > Why is this needed? process-send-string already encodes its argument, > which produces a unibyte string. > > We can't give a multibyte string to process-send-string, because we have to pass the length in bytes in a > header first. Therefore we have to encode any string before passing it to process-send-string. Once you encoded the string, why do you need anything except calling process-send-string?