Re: I created a faster JSON parser

[Eli Zaretskii <eliz@gnu.org>]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Christopher Wellons <wellons@nullprogram.com>,  geza.herman@gmail.com,
>   emacs-devel@gnu.org
> Date: Sun, 10 Mar 2024 21:39:29 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Sat, 9 Mar 2024 15:37:25 -0500
> >> From: Christopher Wellons <wellons@nullprogram.com>
> >> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> >> 
> >> Despite the obvious care which with this was written, I personally would 
> >> not adopt a JSON parser that had not been thoroughly fuzz tested under 
> >> Address Sanitizer and Undefined Behavior Sanitizer. Fuzzing is incredibly 
> >> effective at finding defects, and it would be foolish not to use it in its 
> >> ideal circumstances. Normally it's not difficult and requires only a few 
> >> lines of code. But this JSON parser is tightly coupled with the Emacs Lisp 
> >> runtime, which greatly complicates things. I couldn't simply pluck it out 
> >> by itself and drop it in, say, AFL++.
> >
> > That's okay, we can start by making this an optional feature, and
> > consider making it the default after a couple of major releases;
> > meanwhile, any problems will be detected and reported.
> >
> > However, it would make much more sense to consider switching to this
> > code if it also could handle producing JSON output, thus making
> > libjansson unnecessary when we decide to switch.
> 
> If libjansson is not available, it should still be possible to use this
> faster parser, while falling back to json.el for generating JSON?  From
> what I understand, the main issue people have with JSON is the parsing
> bottleneck, right?

What you describe are possible fallbacks, but I would prefer not to
use any fallback at all, but instead have a full C implementation.

(Using json.el has one unfortunate disadvantage that it's incompatible
with the json.c APIs.)