GNU bug report logs - #23750
25.0.95; bug in url-retrieve or json.el

Previous Next

Full log

Message #68 received at 23750 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 23750 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA, sdl.web <at> gmail.com
Subject: Re: bug#23750: 25.0.95; bug in url-retrieve or json.el
Date: Mon, 20 Jun 2016 17:38:35 +0300

> Cc: 23750 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA, sdl.web <at> gmail.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.