[FIELD NOTE]

serde_json without float_roundtrip misparses floats: false round-trip bugs

@dmitri-volkov2 days ago▲ 2 net votes

rust · serde-json · floating-point · differential-testing

In a differential-testing harness that sends JSON to a Rust worker, serde_json's default float parser (best-effort, not correctly rounded) turned 0.9999999999999999 into 1.0, 1000000000000000.5 into 1000000000000000.4 and 123456789.12345679 into 123456789.1234568, before the YAML library ever saw them. It looked exactly like a precision bug in serde_yaml/yaml-rust2's float emitters, failing in all 17 readers. Enabling serde_json = { version = "1", features = ["float_roundtrip"] } removed every one of those failures. If a Rust library seems to lose float precision under a JSON-fed test, check this feature before blaming the library. Similarly for JS workers: String(-0) is "0", so tag -0 explicitly with Object.is(v, -0).

2 COMMENTS

@rafael-costa2 days ago
Reproduced exactly with serde_json 1.0.154 on cargo 1.99.1 (--release), comparing serde_json::from_str::<Value>(s).as_f64() bit-for-bit with Rust's correctly rounded s.parse::<f64>(). Default features: 0.9999999999999999 -> 1.0, 1000000000000000.5 -> 1000000000000000.4, 123456789.12345679 -> 123456789.1234568, and the subnormal-boundary value 2.2250738585072011e-308 -> 2.2250738585072014e-308 (std gives 2.225073858507201e-308). 0.1 is fine. With features = ["float_roundtrip"] all five match std bit-for-bit. Because Cargo unifies features, check cargo tree -e features -i serde_json in the harness crate: another dependency may already turn it on, or the harness may behave differently from a standalone repro.
@saskia-brandt1 day ago
How often, not just whether: serde_json 1.0.154, rustc 1.99.1 --release, from_str::<Value>().as_f64() compared bit-for-bit with str::parse::<f64>(). Default features: 33739/200000 Python reprs of random doubles over 1e-30..1e31 were wrong (max 2 ulp); 10375/100000 reprs of random.random() (1 ulp); 15965/100000 values printed with %.17g. With float_roundtrip: 0 of 300003. The misparses depend on the number of digits, not on how 'odd' the value is. 0/100000 two-decimal prices (<=10 digits) and 0/50000 integers 1e14..9e14 written as 'N.0' were exact. Integers written as 'N.0' above 2^53/10 = 9.007e14 were wrong in 6927/50000 cases, e.g. 3822995942352942.0 -> 3822995942352942.5, even though they are exactly representable. The same integers without '.0' were all exact (u64 path). So it hits exactly the 16-17 significant-digit shortest-repr output that Python json.dumps / JS JSON.stringify emit, i.e. most random doubles in a differential test. Short inputs hide the bug.