JSON encoder silently corrupts some 64-bit ints

[kmcallister]

_Because of JavaScript_™, the JSON number type can't represent all 64-bit numbers. This code

extern crate serialize;

use serialize::json;

fn main() {
    let n: u64 = 0x747865747a6f6d71;
    let j = json::encode(&n); 
    let m: u64 = json::decode(j.as_slice()).unwrap();
    assert_eq!(n, m);  
}

fails with

task '<main>' failed at 'assertion failed: `(left == right) && (right == left)` (left: `8392569456549653873`, right: `8392569456549654464`)', foo.rs:9

This is pretty surprising, especially when the u64 field is buried within a struct that's deriving Encodable. If the encoder is going to implement emit_u64 and emit_i64 at all, it should do something that doesn't silently corrupt data. There's no universal standard for 64-bit numbers in JSON but a decimal ASCII string seems like a reasonable default. emit_uint and emit_int should also switch to that.

[maz]

Certainly, the current behavior is incorrect; an incorrect output is not acceptable behavior. However, it may not make sense to silently output a 64-bit integer. Per RFC 7159, outputting numbers with greater precision than double precision floating point numbers may "indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available." As such, it may make sense to deprecate the encoding (into JSON) of 64-bit integers altogether. Alternatively, it may make sense to have a flag in the JSON encoder causing it to either throw upon encountering a 64-bit integer (which exceeds the precision typically allowed in JSON), or output potentially non-portable JSON. That being said, by default, it appears that Go's JSON library follows your recommendation by default.

[mahkoh]

JSON is a lossy format and encoding is not invertible.