Denis Gregor e222189360 Check the whole RFC 8259 number grammar in strict mode ...

Strict mode rejected leading zeros but nothing else about the shape of a
number, so several malformed numbers parsed and were then written back out
verbatim, producing JSON that other parsers reject:

    $ echo '[2.e3]' | ./json_parse -s -
    [ 2.e3 ]

RFC 8259 requires a mandatory integer part and at least one digit in both the
fraction and the exponent:

    number = [ minus ] int [ frac ] [ exp ]
    int    = zero / ( digit1-9 *DIGIT )
    frac   = decimal-point 1*DIGIT
    exp    = e [ minus / plus ] 1*DIGIT

so "1.", "-2.", "2.e3", "2.e+3", "0.e1", "-.123", "1e" and "1e+" are all
invalid. Walk the accumulated text against that grammar instead. The leading
zero rule from the previous check is part of the same walk rather than a
separate test, and its cases keep their coverage.

Only JSON_TOKENER_STRICT is affected; the default tokener stays as lenient as
it was. Measured against JSONTestSuite (318 files): strict mode went from 44
to 37 files accepted that the suite says must be rejected, default mode stayed
at 71, and nothing that must be accepted regressed in either mode.

2026-08-16 20:26:15 +03:00

31 KiB

Raw History

View Raw