[Top][All Lists]

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

bug#31138: Native json slower than json.el

From: Eli Zaretskii
Subject: bug#31138: Native json slower than json.el
Date: Wed, 24 Apr 2019 20:06:26 +0300

> Cc: address@hidden, address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Wed, 24 Apr 2019 19:46:16 +0300
> On 24.04.2019 19:21, Eli Zaretskii wrote:
> > Please point me to examples of this, I don't think I understand what
> > you have in mind.
> Buffers with output from a process. In this example, the process is a 
> network connection. Not sure it applies, though. Since output arrives 
> piece-by-piece, maybe it gets decoded with *-string routines 
> (mm-decode-string uses that).

No, I think it's decoded by low-level code which reads output from the
process.  At least by default.

> > What does libjansson do if it receives strings with bytes it cannot
> > interpret?  Like raw bytes or UTF-8 sequences whose length is more
> > than 4 bytes?
> One could test that directly, but its API docs list different kinds of 
> errors, including:
>    json_error_invalid_utf8
>    json_error_null_character
>    json_error_null_byte_in_key
> And we check for error status in functions that use the encoded values.
> Reading the sources, there are several places where the first error is 
> signaled.

The question is, do we want to signal an error ourselves, or do we
want to rely on the library?

(And I need to refresh my memory regarding the differences between the
internal representation of text and strict UTF-8.)

reply via email to

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