How to handle numbers > MAX_SAFE_INTEGER

[richard-uk1]

Numbers is JavaScript are all stored as f64. All the possible values of u32/i32 are representable, but this isn't true for u64/i64. The maximum integer exactly representable in f64 is Number.MAX_SAFE_INTEGER (9007199254740991, or 1 << 53).

Should wasm-bindgen provide any utilities to ensure a number from javascript (f64) is a valid u64 or i64?

Related: #1118, #1149

[alexcrichton]

Yeah handling 64-bit numbers has been pretty unfortunate for us. In JS things "mostly just work" but we need to ascribe a type to everything which means we pick either f64 or u64.

I think one of the best things we can do here is have a function that converts a u64 or i64 into an f64, optionally. That way code can handle the fallible case if necessary, or otherwise as f64 is probably good enough for now.

[richard-uk1]

I thought it was worth having an issue for.

[xtuc]

It would be great to have a way to opt-in in the JavaScript BigInt syntax, especially since WebAssembly will also take advantages of it (i'm trying to push it forward WebAssembly/JS-BigInt-integration#15, that would help).

The wasm-bindgen would return a Bigint literal, probably decoded from the memory, which could be used with other Bigint objects in JavaScript.

[alexcrichton]

@xtuc we've got some very basic support for 64-bit integers today with slices and whatnot, but if you'd like I'd love to dig more in with you at some point to see what we can do in wasm-bindgen to help along the BigInt story (if at all)

[xtuc]

@alexcrichton ok I can take a look before to investigate what's needed, thanks.

[gRoussac]

Hi,

May I ask if there is a way to work around u64 to JsValue ?

this works well

        log(&format!(
            "test {:?}",
            serde_wasm_bindgen::to_value(&rand::thread_rng().gen::<u64>().to_string())
        ));

prints

test Ok(JsValue("341827912451372972"))

and this too

        log(&format!(
            "test {:?}",
            serde_wasm_bindgen::to_value(&rand::thread_rng().gen::<f64>())
        ));

unfortunately back end exclusively sends u64 and not a string

        log(&format!(
            "test {:?}",
            serde_wasm_bindgen::to_value(&rand::thread_rng().gen::<u64>())
        ));

prints
test Err(Error(JsValue(Error: 328383884975377644 can't be represented as a JavaScript number Error: 328383884975377644 can't be represented as a JavaScript number

and I can't change it to string on serialization because of hashes done on data that invalidates as string is not u64 anymore, whole object has to be hashed again with string type.

Would it be possible to be in that case serialized as string if JavaScript number does not fit for u64 ?

Thank you

[daxpedda]

JS BigInt integration is already support by wasm-bindgen, I don't know anything about serde_wasm_bindgen, but wasm_bindgen::JsValue and js_sys::BigInt already support conversion properly.

See #2350.

[gRoussac]

Hi @daxpedda, ok sorry thanks then let me ask serde_wasm_bindgen because I don't see how you would translate any BigInt in json which is typically a javascript global or I miss something.