Follow-up to PR #4093 (typed-array constructor length validation).
The 3-argument typed-array view constructor new TA(buffer, byteOffset, length)
does not validate byteOffset / length against the backing ArrayBuffer, so
out-of-range / misaligned views silently succeed instead of throwing the spec
RangeError.
Repro
new Uint8Array(new ArrayBuffer(8), 7, 4); // Perry: no throw Node: RangeError (offset+len > buffer)
new Uint32Array(new ArrayBuffer(8), 3); // Perry: no throw Node: RangeError (offset % 4 != 0)
new Uint8Array(new ArrayBuffer(8), 16); // Perry: no throw Node: RangeError (offset > byteLength)
(new TA(length) negative/out-of-range validation already works — PR #4093.
DataView(buffer, offset) already validates.)
Why it's deferred
Perry does not yet model real typed-array views — the byteOffset getter is
hardcoded to 0 and the multi-arg form lowers to Expr::New { class_name }
which drops the offset/length args at HIR. Proper validation needs the view to
actually honor byteOffset/length (the underlying feature), at which point the
bounds checks (offset % BYTES_PER_ELEMENT, offset + length*BPE <= byteLength)
fall out naturally.
Part of the #3662 cluster.
Follow-up to PR #4093 (typed-array constructor length validation).
The 3-argument typed-array view constructor
new TA(buffer, byteOffset, length)does not validate
byteOffset/lengthagainst the backingArrayBuffer, soout-of-range / misaligned views silently succeed instead of throwing the spec
RangeError.Repro
(
new TA(length)negative/out-of-range validation already works — PR #4093.DataView(buffer, offset)already validates.)Why it's deferred
Perry does not yet model real typed-array views — the
byteOffsetgetter ishardcoded to
0and the multi-arg form lowers toExpr::New { class_name }which drops the offset/length args at HIR. Proper validation needs the view to
actually honor
byteOffset/length(the underlying feature), at which point thebounds checks (
offset % BYTES_PER_ELEMENT,offset + length*BPE <= byteLength)fall out naturally.
Part of the #3662 cluster.