[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#23750: 25.0.95; bug in url-retrieve or json.el
From: |
Eli Zaretskii |
Subject: |
Re: bug#23750: 25.0.95; bug in url-retrieve or json.el |
Date: |
Wed, 28 Dec 2016 20:27:48 +0200 |
> From: Philipp Stephani <address@hidden>
> Date: Wed, 28 Dec 2016 18:09:52 +0000
> Cc: address@hidden, address@hidden, address@hidden,
> address@hidden
>
>
> [1:text/plain Show]
>
>
> [2:text/html Hide Save:noname (9kB)]
>
> Eli Zaretskii <address@hidden> schrieb am Mi., 30. Nov. 2016 um 19:45 Uhr:
>
> > From: Philipp Stephani <address@hidden>
> > Date: Wed, 30 Nov 2016 18:23:14 +0000
> > Cc: address@hidden, address@hidden, address@hidden
> >
> > > 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?
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, (continued)
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Lars Ingebrigtsen, 2016/12/02
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Dmitry Gutov, 2016/12/02
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Lars Ingebrigtsen, 2016/12/02
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Dmitry Gutov, 2016/12/02
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Eli Zaretskii, 2016/12/03
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Lars Ingebrigtsen, 2016/12/03
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Stefan Monnier, 2016/12/03
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Lars Ingebrigtsen, 2016/12/03
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Andreas Schwab, 2016/12/03
Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Philipp Stephani, 2016/12/28
- Re: bug#23750: 25.0.95; bug in url-retrieve or json.el,
Eli Zaretskii <=
Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Philipp Stephani, 2016/12/28
Re: bug#23750: 25.0.95; bug in url-retrieve or json.el, Philipp Stephani, 2016/12/28