`RevalidateAtomicAccess` will incorrectly fail on valid indices

[Tim Flynn]

For example, consider the following atomic operation:

let array = new Int16Array(4);
Atomics.add(array, 2, 3);

When Atomic.add enters the AtomicReadModifyWrite AO, the first step is:

1. Let indexedPosition be ? ValidateAtomicAccessOnIntegerTypedArray(typedArray, index).

This will ultimately return the following calculation, which converts the requested array index to a byte index:

8. Return (accessIndex × elementSize) + offset.

In the above example, this will be (2 * 2) + 0 = 4. Later on in AtomicReadModifyWrite, we re-validate this index:

4. Perform ? RevalidateAtomicAccess(typedArray, indexedPosition).

This re-validation will always fail the following check in RevalidateAtomicAccess, because, we are comparing a byte-index to the array length:

4. Let length be IntegerIndexedObjectLength(iieoRecord).
5. If indexedPosition ≥ length, throw a RangeError exception.

Should step 4 of RevalidateAtomicAccess instead get the byte length of the array by way of IntegerIndexedObjectByteLength? I think it will also need to consider the current [[ByteOffset]] of the TypedArray in that case.

(I ran into this issue while implementing the merged resizable ArrayBuffer spec changes in Serenity's LibJS).

[Shu-yu Guo]

Oops, good catch. Yes, RevalidateAtomicAccess looks buggy as it is currently.

Should step 4 of RevalidateAtomicAccess instead get the byte length of the array by way of IntegerIndexedObjectByteLength? I think it will also need to consider the current [[ByteOffset]] of the TypedArray in that case.

I think so. But I don't think it needs to consider the [[ByteOffset]] currently because there's no way to repoint an existing TypedArray to a different offset.

Will have a PR up shortly.