Re: I created a faster JSON parser

[Christopher Wellons <wellons@nullprogram.com>]

> It's been running for an hour, the tester didn't find any problems yet.

Except for an overflow assigning huge floats to the dummy Lisp_Object 
value — which is a problem with the test, not the parser — this stripped 
down version looks robust to me, too. Solid work! I have no further 
feedback or commentary.

I made a few tweaks to harden the test, which did not change the results:

* Rather that directly use the AFL input buffer, it uses an exactly-sized 
copy so that it could detect out of bounds access on input.

* Used a custom malloc that initializes memory to garbage.

* Used a custom realloc that always moves, and initializes extended memory 
to garbage.

> it incorrectly optimizes around setjmp in do_test()

If a program modifies a variable after the first setjmp return and then 
accesses it after the second setjmp return, it must be volatile-qualified. 
GCC and Clang have some machinery to mitigate a lack of volatile, such as 
the returns_twice attribute, but technically it's required. I believe in 
practice using either builtin setjmp/longjmp or a memory barrier would be 
sufficient, but my system's Clang doesn't exhibit the stale pointer here, 
so I can't test that theory.