Re: [whatwg/webidl] Fix `BufferSource` algorithms for shared and resizable buffers (PR #1529)

@MattiasBuelens commented on this pull request.



> @@ -9312,26 +9312,65 @@ a reference to the same object that the IDL value represents.
     To <dfn id="dfn-get-buffer-source-copy" export lt="get a copy of the buffer source|get a copy of the bytes held by the buffer source">get a copy of the bytes held by the buffer source</dfn>
     given a [=buffer source type=] instance |bufferSource|:
 
-    1.  Let |jsBufferSource| be the result of [=converted to a JavaScript value|converting=]
-        |bufferSource| to a JavaScript value.
-    1.  Let |jsArrayBuffer| be |jsBufferSource|.
+    1.  If |bufferSource| is [=BufferSource/detached=], then return the empty [=byte sequence=].

With tc39/ecma262#3972, "byte length" and "byte offset" now return 0 for out-of-bounds `DataView`s too (3ae5bf0, 4496852), so detached and out-of-bounds views are both reported as having a byte length of 0.

That means this step didn't need an "is out of bounds" check at all: I've removed the "is detached" check, so the existing "If |length| is 0" check now covers both cases uniformly (bfe0173).

As for the other detachedness checks, I went through them, but I don't think any of them should become an out-of-bounds check:
* "Byte length" of a plain `ArrayBuffer` or `SharedArrayBuffer` checks `IsDetachedBuffer`, since buffers themselves can't be out of bounds.
* "Detached", "transferable", "transfer" and "detach" are about detaching and transferring the buffer itself, where being out of bounds doesn't matter. (A view on a shrunk buffer doesn't stop that buffer from being transferred.)
* "Write" into an `ArrayBufferView` already asserts that the view is not out of bounds, which implies it's not detached either.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1529#discussion_r4367087346
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1529/review/5638205363@github.com>

Received on Saturday, 24 October 2026 12:16:25 UTC