util: add isArrayBufferDetached method

[anonrig]

CC @nodejs/streams @nodejs/util @nodejs/performance

[anonrig]

CC @daeyeon, since he was the original author of this TODO.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/48014/

[tniessen]

b) Should this really be a public API?

Adding to @addaleax's point, if there is justification for such a public API in Node.js, isn't there justification for such an API in any JavaScript runtime, in which case it would be better to find a compatible approach across runtimes?

[anonrig]

b) Should this really be a public API?

Adding to @addaleax's point, if there is justification for such a public API in Node.js, isn't there justification for such an API in any JavaScript runtime, in which case it would be better to find a compatible approach across runtimes?

I'm +0 on the public API. But I don't think there is a better & compatible approach across runtimes (for now), since WasDetached is not currently supported at Deno (using V8 10.9.194.1)

[ljharb]

If a universal solution is desired, and there's compelling use cases for it, a JS language proposal seems appropriate.

[mcollina]

What's the use case for this? The PR description is empty.

[LiviaMedeiros]

Should we do this before checking if value is an instance of ArrayBuffer?

[aduh95]

If the user passes something that's not an ArrayBuffer, instead of returning false the function would throw a TypeError, which is surprising. We should at least document this behavior if we want to keep it (another option is to not expose it publicly and keep it internal, or expose a slower version that first checks if the parameter is an ArrayBuffer before calling the internal util).

[jasnell]

@mcollina:

What's the use case for this? The PR description is empty.

There are a few cases (e.g. in web streams) where we are required to check if the ArrayBuffer has been detached. Currently we only approximate the check by seeing if it is a zero-length ArrayBuffer, but that's really not quite accurate.

[mcollina]

If we need it only for our webstreams API, it would be better to:

1. only expose it internally
2. include those usages in the PR

[LiviaMedeiros]

If performance cost of checking if ArrayBuffer is detached will be negligible, it would make sense to widely use it in other parts of Node.js API.
In most cases, passing a view with detached buffer is meaningless and implies an error in userland code. Currently, the outcome depends on underlying implementation:

• If it tries to use the buffer (e.g. make a new view with new Uint8Array(passedData.buffer), or a copy with passedData.slice()), the TypeError will be thrown.
• Otherwise it's silently interpreted as zero-size buffer; for example, fs.writeFileSync(filePath, dataBuffer) will truncate file to zero if dataBuffer.buffer happens to be detached.

[anonrig]

I'm working with @ljharb on making a proposal to TC39 for detach and isDetached. Until, it is released, I wanted to give the option to both functionality to detach and detect isDetached to the userland. This is one of the first pull request, when/if merged, will be continued with detachArrayBuffer() functionality. Some of the reviews on this pull request was around why we should expose isDetached to the userland.

This particular question is better answered with the original ArrayBuffer.prototype.transfer() proposal.

[aduh95]

I wouldn't be surprised if that instanceof check had a dramatic impact on performance.

[anonrig]

Referencing: https://github.com/RafaelGSS/nodejs-bench-operations/blob/main/RESULTS-v19.md#comparison-using-instanceof

I can change it to value != null && ... , and expect .byteLength to be the differentiator.

[aduh95]

I think the best course of action is to make an internal isArrayBufferDetached without any instanceof check, and if we have a public one, it would return value instanceof ArrayBuffer && internal.isArrayBufferDetached(value).

[anonrig]

@aduh95#45568

[ljharb]

also, instanceof is brittle and can be forged, and doesn’t work cross-realm. In JS the way to check this is using the byteLength getter in a try/catch.

[anonrig]

I'm closing this pull request in favor of Array.prototype.detached proposal, which is currently in Stage 2.