Fix byteOffset for detached array buffers #418
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The spec [1] expects to read `byteOffset` even for detached buffers. Noticed a new test262 test [2] failed and there an an existing one we skipped as well for the same reason. [1] https://tc39.es/ecma262/#sec-%typedarray%.prototype.subarray [2] https://github.com/tc39/test262/blob/main/test/built-ins/TypedArray/prototype/subarray/byteoffset-with-detached-buffer.js Fix: bellard#417
``` E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Error: Process completed with exit code 100. ``` As the error suggests `apt update` seems to fix it
nickva
added a commit
to nickva/quickjs
that referenced
this pull request
Jun 29, 2025
Previously, in issue bellard#418 and pr bellard#417 I misread the spec that in `subarray` we should be able to access the `byteOffset` from a detached buffer. Thinking more about it, something didn't seem right and I started a discussion in the TC39 group [1]. It turns out we shouldn't be able to read the ``byteOffset`` from detched buffers. Instead, the spec says we should just read the `byteOffset` value before we access `start` and `finish`. In the test262 test [2] the buffer is detached when accessing the `end` inside the `valueOf()` conversion, and the test expects to see the `byteOffset` before it was detached. So to fix it, ensure we access and save the `byteOffset` value first, then get the `start` and `finish`. [1] https://es.discourse.group/t/typedarray-subarray-byteoffset-with-detached-buffers/2381 [2] https://github.com/tc39/test262/blob/main/test/built-ins/TypedArray/prototype/subarray/byteoffset-with-detached-buffer.js
nickva
added a commit
to nickva/quickjs
that referenced
this pull request
Jun 29, 2025
Previously, in issue bellard#418 and pr bellard#417 I misread the spec that in `subarray` we should be able to access the `byteOffset` from a detached buffer. Thinking more about it, something didn't seem right and I started a discussion in the TC39 group [1]. It turns out we shouldn't be able to read the ``byteOffset`` from detched buffers. Instead, the spec says we should just read the `byteOffset` value before we access `start` and `finish`. In the test262 test [2] the buffer is detached when accessing the `end` inside the `valueOf()` conversion, and the test expects to see the `byteOffset` before it was detached. So to fix it, ensure we access and save the `byteOffset` value first, then get the `start` and `finish`. [1] https://es.discourse.group/t/typedarray-subarray-byteoffset-with-detached-buffers/2381 [2] https://github.com/tc39/test262/blob/main/test/built-ins/TypedArray/prototype/subarray/byteoffset-with-detached-buffer.js
nickva
added a commit
to nickva/quickjs
that referenced
this pull request
Jun 29, 2025
Previously, in issue bellard#418 and pr bellard#417 I misread the spec that in `subarray` we should be able to access the `byteOffset` from a detached buffer. Thinking more about it, something didn't seem right and I started a discussion in the TC39 group [1]. It turns out we shouldn't be able to read the ``byteOffset`` from detched buffers. Instead, the spec says we should just read the `byteOffset` value before we access `start` and `finish`. In the test262 test [2] the buffer is detached when accessing the `end` inside the `valueOf()` conversion, and the test expects to see the `byteOffset` before it was detached. So to fix it, ensure we access and save the `byteOffset` value first, then get the `start` and `finish`. [1] https://es.discourse.group/t/typedarray-subarray-byteoffset-with-detached-buffers/2381 [2] https://github.com/tc39/test262/blob/main/test/built-ins/TypedArray/prototype/subarray/byteoffset-with-detached-buffer.js
nickva
added a commit
to nickva/quickjs
that referenced
this pull request
Jun 29, 2025
Previously, in issue bellard#418 and pr bellard#417 I misread the spec that in `subarray` we should be able to access the `byteOffset` from a detached buffer. Thinking more about it, something didn't seem right and I started a discussion in the TC39 group [1]. It turns out we shouldn't be able to read the ``byteOffset`` from detched buffers. Instead, the spec says we should just read the `byteOffset` value before we access `start` and `finish`. In the test262 test [2] the buffer is detached when accessing the `end` inside the `valueOf()` conversion, and the test expects to see the `byteOffset` before it was detached. So to fix it, ensure we access and save the `byteOffset` value first, then get the `start` and `finish`. [1] https://es.discourse.group/t/typedarray-subarray-byteoffset-with-detached-buffers/2381 [2] https://github.com/tc39/test262/blob/main/test/built-ins/TypedArray/prototype/subarray/byteoffset-with-detached-buffer.js
nickva
added a commit
to nickva/quickjs
that referenced
this pull request
Jun 29, 2025
Previously, in issue bellard#418 and pr bellard#417 I misread the spec that in `subarray` we should be able to access the `byteOffset` from a detached buffer. Thinking more about it, something didn't seem right and I started a discussion in the TC39 group [1]. It turns out we shouldn't be able to read the ``byteOffset`` from detched buffers. Instead, the spec says we should just read the `byteOffset` value before we access `start` and `finish`. In the test262 test [2] the buffer is detached when accessing the `end` inside the `valueOf()` conversion, and the test expects to see the `byteOffset` before it was detached. So to fix it, ensure we access and save the `byteOffset` value first, then get the `start` and `finish`. [1] https://es.discourse.group/t/typedarray-subarray-byteoffset-with-detached-buffers/2381 [2] https://github.com/tc39/test262/blob/main/test/built-ins/TypedArray/prototype/subarray/byteoffset-with-detached-buffer.js
nickva
added a commit
to nickva/quickjs
that referenced
this pull request
Jun 29, 2025
Previously, in issue bellard#418 and pr bellard#417 I misread the spec that in `subarray` we should be able to access the `byteOffset` from a detached buffer. Thinking more about it, something didn't seem right and I started a discussion in the TC39 group [1]. It turns out we shouldn't be able to read the ``byteOffset`` from detched buffers. Instead, the spec says we should just read the `byteOffset` value before we access `start` and `finish`. In the test262 test [2] the buffer is detached when accessing the `end` inside the `valueOf()` conversion, and the test expects to see the `byteOffset` before it was detached. So to fix it, ensure we access and save the `byteOffset` value first, then get the `start` and `finish`. [1] https://es.discourse.group/t/typedarray-subarray-byteoffset-with-detached-buffers/2381 [2] https://github.com/tc39/test262/blob/main/test/built-ins/TypedArray/prototype/subarray/byteoffset-with-detached-buffer.js
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Read byteOffset for detached buffers
The spec expects to read
byteOffseteven for detached buffers.Noticed a new test262 test failed and there is an existing one we skipped as well for the same reason.
Fix: #417