[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31138: Native json slower than json.el

From: Philipp Stephani
Subject: bug#31138: Native json slower than json.el
Date: Tue, 23 Apr 2019 11:46:58 +0200

Am Di., 23. Apr. 2019 um 08:00 Uhr schrieb Eli Zaretskii <address@hidden>:
> > Cc: address@hidden, address@hidden, address@hidden,
> >  address@hidden
> > From: Dmitry Gutov <address@hidden>
> > Date: Tue, 23 Apr 2019 01:23:44 +0300
> >
> > On 22.04.2019 20:26, Eli Zaretskii wrote:
> > > I don't think we should abort, we don't do that anywhere else.
> >
> > The key word here is "validation". If certain folks in this discussion
> > are right, libjansson always returns valid utf-8 encoded strings, or
> > intends to.
> >
> > So if we implement fast validation for multibyte strings as well, the
> > "else" branch should never be taken, and it would make sense to abort in
> > that case. Not necessarily abort as in "exit Emacs", but maybe signal an
> > error. The libjansson developers might in the end be thankful for bug
> > reports.
> The interests of libjansson developers aside, I disagree that
> low-level text decoding functionality should signal an error, let
> alone abort.  It is up to the application to decide whether having raw
> bytes in strings is legit or not.  This is our policy everywhere,
> including when UTF-8 is the standard encoding, so I don't think this
> case is special in any way.

It's special in the sense that both the JSON RFC and Jansson require
UTF-8 for interchange, so we don't have to deal with raw bytes and can
assume all text is UTF-8-encoded. The test suite contains a few tests
to ensure that passing non-UTF-8-strings always results in an error.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]