BigUint64Array some large numbers broken in wasm32-wasi

[lastmjs]

Here's a very simple reproducible piece of code that shows the issue:

// This should print an element with value 18446600000000000000n
// It actually prints an element with value 18446740737488355328n
const bytes = [0, 128, 184, 57, 247, 124, 255, 255];
const buffer = new ArrayBuffer(8);
const uint8Array = new Uint8Array(buffer);
uint8Array.set(bytes);
const bigUint64Array = new BigUint64Array(buffer);
console.log(bigUint64Array[0].toString());

Some large numbers relatively close to the maximum size of an unsigned 64 bit integer (2^64 - 1 or 18_446_744_073_709_551_615) are not able to be put into the new BigUint64Array constructor. The resulting BigUint64Array has a number that is not the same as the number being passed into the constructor.

The code above returns the correct number 18446600000000000000n on Node.js, Chrome, QuickJS compiled to my Ubuntu machine, Javy running on my Ubuntu machine, and rquickjs running on my Linux machine. Javy compiled to wasm32-wasi and rquickjs compiled to wasm32-wasi both return the incorrect number 18446740737488355328n. I've used both wasmtime and wasmer to test that the incorrect number is returned.

Other numbers are broken as well.

[lastmjs]

Here's some more interesting code that creates the same BigUint64Array differently. As soon as the number is assigned into the BigUint64Array the damage is done. bigIntValue is correct the whole time, it's when we read the first element of the BigUint64Array that the number appears to becomes corrupted:

const bytes = [0, 128, 184, 57, 247, 124, 255, 255];

let bigIntValue = BigInt(0);
for (let i = 0; i < bytes.length; i++) {
    bigIntValue =
        (bigIntValue << BigInt(8)) +
        BigInt(bytes[bytes.length - 1 - i]);
}

const bigUint64Array = new BigUint64Array(1);
bigUint64Array[0] = bigIntValue;
console.log(bigUint64Array[0].toString());

[ulan]

I narrowed down the problem to this line in code: https://github.com/bellard/quickjs/blob/2788d71e823b522b178db3b3660ce93689534e6d/quickjs.c#L12031

Something goes wrong after the call to bf_set_ui(a, v).

Google search for that function shows: #131

If I apply the fix of that issue locally, then the problem disappears: #132

[bellard]

fixed

[ulan]

@bellard: thanks a lot for pushing the fix. There are other occurrences of LIMB_BITS - shift that potentially have similar issues. Here is a patch I was testing locally: ulan/javy@984b8d1

Do you think those places are safe or should also be fixed?

[bellard]

Normally there is a check before. Adding unnecessary tests is expensive and should be avoided.