Implementing FMA and finding bugs in C and Rust standard libraries

The standard library alone is insufficient for guaranteed JSON validation in Rust. After spending a weekend building a JSON toolkit with zero external dependencies, I discovered that 10% of JSON documents rejected by RFC 8259 are still accepted by Rust's default number parsing. Examples include NaN, Infinity, 5., .5, +1, and 012.

These invalid JSON elements are accepted by functions like f64::from_str and i64::from_str, which do not enforce the strict JSON specification. My JSON parser, jaq-lite, supports a range of JSON features while maintaining compliance with RFC 8259. It includes identity, field access, indexed access, iteration, pipes, commas, parentheses, the optional operator ?, and eleven built-in functions.

Exit codes from jaq-lite follow the jq standard: 2 for bad flags, 3 for uncompiled filters, 5 for non-JSON input, and 0 for successful execution. The JSONTestSuite is used as the standard conformance corpus, containing 318 parsing files and 35 invalid number cases. Delegating validation to Rust's standard library's from_str function proved inadequate, as it accepted nineteen invalid JSON number literals without error messages or warnings.

The issue lies in the conversion function's permissive nature, not in Rust itself. Consequently, when exchanging JSON data with Python or JavaScript services, it is essential to handle potential validation discrepancies.