Re: I created a faster JSON parser

[Christopher Wellons]

> What do you think?

Your new JSON parser appears to carefully written, and has the marks of 
thoughtful design. You've avoided the common pitfalls, and that gives me 
confidence in it.

In review I noticed a potential pointer overflow in json_parse_string:

parser->input_current + 4 <= parser->input_end

The "+ 4" may push the pointer beyond one-past-the-end not just for the 
input, but the buffer itself, overflowing the pointer. To fix, re-arrange 
the expression to check a size rather than an address:

parser->input_end - parser->input_current >= 4

In json_make_object_workspace_for and json_byte_workspace_put, a size is 
doubled without an overflow check ("new_workspace_size * 2"). The first 
could cause an infinite loop, and the second could allocate less than was 
expected. Both are minor, and in practice can only affect 32-bit targets, 
because you'd need to grow these buffers to the limits before these sizes 
could overflow.

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++.

As noted earlier, the parser gets its performance edge through skipping 
the intermediate steps. This is great! That could still be accomplished 
without such tight coupling, allowing for performance *and* an interface 
that is testable and fuzzable in relative isolation.