Re: JSON/YAML/TOML/etc. parsing performance

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Mo., 9. Okt. 2017 um 08:54 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Sun, 08 Oct 2017 23:14:18 +0000
> > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> >
> > Jansson only accepts UTF-8 strings, and at least in our usage will also
> only hand out UTF-8 strings.
>
> How can we be 100% sure of that?  We don't trust any other libraries
> with such high fidelity, we always decode any external data.
>

We also trust glibc's malloc to never return overlapping non-freed blocks,
right? This "trust" isn't different. Of course we can assume that libraries
behave according to their specification.


>
> > It's totally OK to rely on this assumption since all code that's
> involved here is part of the Emacs core, so it can
> > rely on implementation details.
>
> That is in stark contrast with your usual coding style, which tends to
> place checks and assertions where they are not always needed.


I wouldn't mind placing an assertion here as well. An assertion primarily
documents the assumptions made in the code and as a side effect is also
tested in debug builds. It's generally a good idea to add such
documentation.


>   Could
> it be that you underestimate the damage that broken non-ASCII byte
> stream can cause Emacs if inserted directly into a buffer or a string?
> Doing so will usually cause Emacs die a horrible death quite soon,
> because code that processes buffer or string text has no defenses
> against such calamities.
>

If and when such a bug happens, we can work around it (after filing a bug
against Jansson). But we can't work around potential bugs in libraries, see
above.

[-- Attachment #2: Type: text/html, Size: 2515 bytes --]