Skip to content
This repository was archived by the owner on Oct 24, 2023. It is now read-only.

Normative: Don't consider 0-length TypedArrays out of bounds #70

Merged
merged 1 commit into from
Aug 18, 2021

Conversation

syg
Copy link
Collaborator

@syg syg commented Aug 2, 2021

Closes #68

@syg syg merged commit 8fbb531 into master Aug 18, 2021
@syg syg deleted the fix-oob-zero-len branch August 18, 2021 23:43
@bakkot
Copy link
Contributor

bakkot commented Aug 18, 2021

The NOTE says "0-length TypedArrays", but this only applies to 0-length TAs which start at precisely the end of the underlying buffer, right?

@syg
Copy link
Collaborator Author

syg commented Aug 19, 2021

Correct.

jugglinmike added a commit to tc39/test262 that referenced this pull request Aug 25, 2021
A recent normative change to the Resizable ArrayBuffer modified the
criteria for a TypedArray becoming "out of bounds." Following the
change, TypedArrays which track the length of their underlying
ArrayBuffer instance are no longer considered "out of bounds" when the
ArrayBuffer is resized such that its size matches the TypedArray's
offset exactly.

tc39/proposal-resizablearraybuffer#70

The majority of this patch's changes extend coverage to include cases
for both "on boundary" and "out of bounds" without reflecting any new
semantics. Two changes describe observable differences in the new
version of the algorithm:

- out-of-bounds-when-species-retrieved-different-type.js
- out-of-bounds-when-species-retrieved-same-type.js
@jugglinmike
Copy link
Contributor

Corresponding Test262 changes: tc39/test262#3163

rwaldron pushed a commit to tc39/test262 that referenced this pull request Aug 25, 2021
A recent normative change to the Resizable ArrayBuffer modified the
criteria for a TypedArray becoming "out of bounds." Following the
change, TypedArrays which track the length of their underlying
ArrayBuffer instance are no longer considered "out of bounds" when the
ArrayBuffer is resized such that its size matches the TypedArray's
offset exactly.

tc39/proposal-resizablearraybuffer#70

The majority of this patch's changes extend coverage to include cases
for both "on boundary" and "out of bounds" without reflecting any new
semantics. Two changes describe observable differences in the new
version of the algorithm:

- out-of-bounds-when-species-retrieved-different-type.js
- out-of-bounds-when-species-retrieved-same-type.js
jugglinmike added a commit to tc39/test262 that referenced this pull request Sep 23, 2021
Following a recent normative change to the Resizable ArrayBuffer
proposal [1], the term "out of bounds" no longer applies to
"length-tracking" TypedArrays whose underlying ArrayBuffer has been
resized to match their byte offset.

Reflect this in the tests by renaming the condition from "out of bounds"
to "on boundary" and by adding new assertions for true "out of bounds"
conditions.

[1] tc39/proposal-resizablearraybuffer#70
rwaldron pushed a commit to tc39/test262 that referenced this pull request Sep 23, 2021
Following a recent normative change to the Resizable ArrayBuffer
proposal [1], the term "out of bounds" no longer applies to
"length-tracking" TypedArrays whose underlying ArrayBuffer has been
resized to match their byte offset.

Reflect this in the tests by renaming the condition from "out of bounds"
to "on boundary" and by adding new assertions for true "out of bounds"
conditions.

[1] tc39/proposal-resizablearraybuffer#70
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should length-tracking TAs be considered OOB when O.[[ByteOffset]] == bufferByteLength?
3 participants