mirror/json-c
1
0
Fork 0
mirror of https://github.com/json-c/json-c.git synced 2026-09-07 16:46:50 +08:00
Code Issues Packages Projects Releases Wiki Activity

Check the whole RFC 8259 number grammar in strict mode

Browse Source 
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.
This commit is contained in:
Denis Gregor
2026-08-16 20:26:15 +03:00
parent 892c204ce0
commit e222189360
3 changed files with 89 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/test_parse.c
+18
View File
@@ -375,6 +375,24 @@ struct incremental_step
/* ... but a lone zero, "-0" and a zero before the fraction stay valid. */
{"[-0]", -1, -1, json_tokener_success, 1, JSON_TOKENER_STRICT},
{"[0.5]", -1, -1, json_tokener_success, 1, JSON_TOKENER_STRICT},
/* RFC 8259 wants a digit either side of the decimal point and after the
* exponent marker, so a bare "1." or "2.e3" is not a number ... */
{"[1.]", -1, 3, json_tokener_error_parse_number, 1, JSON_TOKENER_STRICT},
{"[-2.]", -1, 4, json_tokener_error_parse_number, 1, JSON_TOKENER_STRICT},
{"[2.e3]", -1, 5, json_tokener_error_parse_number, 1, JSON_TOKENER_STRICT},
{"[2.e+3]", -1, 6, json_tokener_error_parse_number, 1, JSON_TOKENER_STRICT},
{"[0.e1]", -1, 5, json_tokener_error_parse_number, 1, JSON_TOKENER_STRICT},
{"[1e]", -1, 3, json_tokener_error_parse_number, 1, JSON_TOKENER_STRICT},
{"[1e+]", -1, 4, json_tokener_error_parse_number, 1, JSON_TOKENER_STRICT},
/* ... and the integer part is mandatory, so "-.123" is not a number either
* (a bare ".5" never reaches the number state at all). */
{"[-.123]", -1, 6, json_tokener_error_parse_number, 1, JSON_TOKENER_STRICT},
/* The well-formed spellings of the same values stay valid. */
{"[1.0]", -1, -1, json_tokener_success, 1, JSON_TOKENER_STRICT},
{"[2e3]", -1, -1, json_tokener_success, 1, JSON_TOKENER_STRICT},
{"[2E-3]", -1, -1, json_tokener_success, 1, JSON_TOKENER_STRICT},
{"[0.123]", -1, -1, json_tokener_success, 1, JSON_TOKENER_STRICT},
{"[-0.123]", -1, -1, json_tokener_success, 1, JSON_TOKENER_STRICT},
{"0e+0", 5, 4, json_tokener_success, 1, 0},
{"[0e+0]", -1, -1, json_tokener_success, 1, 0},