From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23750: 25.0.95; bug in url-retrieve or json.el Date: Mon, 20 Jun 2016 17:38:35 +0300 Message-ID: <838ty07wno.fsf@gnu.org> References: <358304f6-98e1-fa10-8805-aa9b73db406a@yandex.ru> <83k2hl828z.fsf@gnu.org> <83h9co8twu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1466434077 7781 80.91.229.3 (20 Jun 2016 14:47:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 14:47:57 +0000 (UTC) Cc: 23750@debbugs.gnu.org, monnier@IRO.UMontreal.CA, sdl.web@gmail.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 20 16:47:46 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1bF0UI-0003Nf-HN for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 16:47:42 +0200 Original-Received: from localhost ([::1]:44086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF0UH-0003Hu-OD for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 10:47:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF0Mv-0002cp-3w for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 10:40:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF0Ms-0005Ec-1Y for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 10:40:04 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF0Mr-0005EU-V4 for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 10:40:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bF0Mr-0006N3-RS for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 10:40:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Jun 2016 14:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23750 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23750-submit@debbugs.gnu.org id=B23750.146643358824464 (code B ref 23750); Mon, 20 Jun 2016 14:40:01 +0000 Original-Received: (at 23750) by debbugs.gnu.org; 20 Jun 2016 14:39:48 +0000 Original-Received: from localhost ([127.0.0.1]:47822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0Md-0006MW-Te for submit@debbugs.gnu.org; Mon, 20 Jun 2016 10:39:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37060) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF0Mb-0006MG-F8 for 23750@debbugs.gnu.org; Mon, 20 Jun 2016 10:39:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF0MU-00055P-GJ for 23750@debbugs.gnu.org; Mon, 20 Jun 2016 10:39:40 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF0MM-00051j-Cz; Mon, 20 Jun 2016 10:39:30 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3425 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bF0MK-0007iX-E4; Mon, 20 Jun 2016 10:39:28 -0400 In-reply-to: (message from Dmitry Gutov on Mon, 20 Jun 2016 05:51:06 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:119833 Archived-At: > Cc: 23750@debbugs.gnu.org, monnier@IRO.UMontreal.CA, sdl.web@gmail.com > From: Dmitry Gutov > Date: Mon, 20 Jun 2016 05:51:06 +0300 This all sounds like my response is not welcome, but in that case why did you ask the question? Anyway: > So this is not a bug in Emacs, but a diagnostic facility to let bugs > in applications be discovered? > > It's a bug. Accepting invalid input and behaving badly with it is definitely a bug. No, the bug is where the invalid input is generated in the first place. Each API has its contract; if you violate the contract, you invoke undefined behavior. > If this is what you need, why not simply test the payload for being a > unibyte string? There a function, multibyte-string-p, for that. > > There are a lot of variables to test (see the comment above the mapconcat call). Looks like mapc will be able to deal with that. Or just use concat, and test the result with multibyte-string-p before sending. Or encode it with UTF-8, if it is not unibyte already. Btw, I don't think the comment which explains why we started using mapconcat is accurate these days. It was written before the move to Unicode in Emacs 23, but we stopped converting raw bytes into Latin-1 characters in Emacs 23 and later. So maybe we should just go back to using concat (with erroring out, if the result is multibyte, and/or maybe with replacing 'length' with 'string-bytes'). Bottom line: like I said, there should be no reason to use string-*-unibyte in modern Emacs code on the url-http level or higher (maybe not at all). Its use is a sign of some basic misunderstanding, or a bug elsewhere, or remnant of old problems that no longer exist. So I think we should reconsider the solution on master as well. > I'm fine either way, but my patch changes two characters, and yours will be longer. I don't think the quality of a change should be judged by the number of characters in the patch. That is a very strange criterion, to say the least. It would mean, for example, that changes with comments are worse than changes without comments, or that saving newlines in C code (which makes the code less readable) is a virtue. > And you'll have to come up with the error message(s). Are you saying you like the error message from string-to-unibyte? Cannot convert 123th character to unibyte Doesn't really strike me as something that a user or an average developer will understand. I thought you wanted something more human-readable, like Invalid multibyte text in HTTP request %s