unint64_t is passed through to JS as a signed value instead

[cuberoot]

While trying to pass std::numeric_limits<uint64_t>::max() through to JS in bigint mode, I hit an issue where I get a -1 on the JS side. I would expect the value to come through correctly as bigint can represent a number that large.

I can reproduce this with a cpp file with a JS library as follows:

Put this in main.cpp

#include <iostream>
#include <emscripten/bind.h>
#include <emscripten/emscripten.h>

extern "C" {
  extern void my_js(uint64_t value);
}

int main() {
    std::cout << std::numeric_limits<uint64_t>::max() << std::endl;
    my_js(std::numeric_limits<uint64_t>::max());

    return 0;
}

Put this in main.js:

mergeInto(LibraryManager.library, {
    my_js: function(value) {
        console.log('value', value);
    },
});

Then compile with this command:

emcc --js-library main.js -s WASM_BIGINT main.cpp -o test.html

This gives me the following output when I load test.html:

18446744073709551615
test.js:4286 value -1n

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[mmarczell-graphisoft]

@juj @kripken @sbc100 I would be interested in working on this, but I have no idea where to start. Any ideas?

[sbc100]

The issue I believe is that at the boundary of JS and Wasm we only have i32 and i64 and interpreting those types as either signed or unsigned is up to the embedder (in this case JS).

In this example the JS library function doesn't actually know the signature of the native function, and neither the wasm module since the type was lowered to i64 during compilation.

I'm not even sure how to go about reinterpreting the BigInt here as an unisigned i64. Perhaps one could write it do a DataView via .setBigInt64() and then read it back via .getBigUint64() but that seems like overkill.

[juj]

I hit an issue where I get a -1 on the JS side. I would expect the value to come through correctly as bigint can represent a number that large.

When JS side code receives values from Wasm, they will all come out as signed Numbers, or now as BigInts when supported and enabled. Wasm does not really have any machinery to know the intended interpretation of the signed vs unsigned aspect, so there will always be a need for the JS side to "fix up" the received numbers it gets.

#15433 aims to resolve some issues around this. Also, there exists the library src/library_int53.js today, which can help non-BigInt uses.

However neither of those will help the 64-bit unsigned integer aspect. To fix that, off the top of my head I can't think of anything better except to convert via arithmetic. One can do

const i64ToU64Offset = BigInt(2)**BigInt(64); // In the future can write this as "2n**64n" when Emscripten's terser is updated with BigInt literal support
function convertBigI64ToBigU64(signedBigInt) {
  return signedBigInt < 0 ? i64ToU64Offset - signedBigInt : signedBigInt;
}

Then in the JS functions that receive a BigInt that should be an unsigned 64-bit thing, you can call convertBigI64ToBigU64(arg) on each to convert to 64-bit unsigned form.

[logankaser]

I also see this with embind and value_object,
A struct with an std::uint64_t data member will appear in JS as negative if
over std::numeric_limits<int64_t>::max(), is this the same issue?
Should I open a separate ticket for that?

[logankaser]

Small bug in that snippet, i64ToU64Offset - signedBigInt should be i64ToU64Offset + signedBigInt as we know signedBigInt is negative.

const i64ToU64Offset = BigInt(2)**BigInt(64); // In the future can write this as "2n**64n" when Emscripten's terser is updated with BigInt literal support
function convertBigI64ToBigU64(signedBigInt) {
  return signedBigInt < 0 ? i64ToU64Offset + signedBigInt : signedBigInt;
}