Re: [review] [json] My JSON review

From: Peter Dimov (pdimov_at_[hidden])
Date: 2020-09-21 14:59:36

> Assuming you have the number 12345678909876543210, which is striding two 
> buffers, with 1234567890 then 9876543210, the parser will call
>
> uint64 value = 0;
>
> value = value * pow10(size("1234567890")) + 1234567890;
> on_number_part("1234567890", ec)
>
> value = value * pow10(size("9876543210")) + 9876543210;
> on_uint64(value, "9876543210", ec)
>
> (the actual implementation works on character per character basis and is 
> slower than this)
>
> This will not really work once the value gets one digit larger, as the 
> first argument will be garbage.

But if the value gets larger, the parser will not call on_uint64, it will 
call on_double.

> The text to binary conversion shouldn't even be in the JSON parser,

OK, if you don't need the text to binary conversion, what's stopping you 
from ignoring it, and only using the text part? You do get all the info, 
it's just that the final part doesn't arrive via "on_number", but via the 
other three callbacks, to save one call.

> > What are the limitations, and what is `n` in your suggested replacement?
>
> Same as for on_string_part/on_string, on_key_part/on_key, 
> on_comment_part/on_comment etc.
>
> I'm arguing it should be there for consistency, it's not strictly 
> necessary.

Yeah, fair point.