Re: I created a faster JSON parser

[Herman , Géza]

Eli Zaretskii <eliz@gnu.org> writes:

> > From: Herman, Géza <geza.herman@gmail.com>
> > That was a mistake on my part, though a different (but similar)
> > one.  I originally used a 64-bit type, but then changed it to
> > long, because of 32-bit architectures.  The idea is to use a 
> > type
> > which likely has the same size as a CPU register.
>
> If you want to use a 32-bit type, use 'int' or 'unsigned int'.
I want to use a datatype which is likely to have the same size as 
a CPU register. On 32-bit machines, it should be 32-bit, on 64-bit 
architectures it should be 64-bit.  This is not a strong 
requirement, but it makes the parser faster.  During number 
parsing, this part of the code calculates the value of the 
number. If it overflows, or it ends up being a float, then the 
workspace buffer is re-parsed to find the value. But if it is an 
integer without overflow, the parser just can use the value 
without any further processing (a certain kind of LSP message is 
basically a large array of integers, so it makes sense to optimize 
this case - this optimization makes parsing such messages 1.5-2x 
faster).

> We need to decide what to do with characters outside of the 
> Unicode
> range.  The encoding of those characters is different, btw, it 
> doesn't
> follow the UTF-8 scheme.
>
> In any case, the error in those cases cannot be just "json parse
> error", it must be something more self-explanatory.
I am open to suggestions, as even after reading "Text 
Representations" in the manual, I have no idea what to do here.  I 
didn't find any code which handles this case in the jansson parser 
either.