Repository navigation
Buffer.from(<ArrayBufferView>) #43862
Description
Activity
- addedfeature requestIssues requesting new Node.js features.Issues requesting new Node.js features.bufferIssues and PRs related to the buffer subsystem.Issues and PRs related to the buffer subsystem.
on Jul 16, 2022 There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jan 13, 2023 This should be kept open. It's still needed
- addednever-staleIssues and PRs exempt from automated stale handling.Issues and PRs exempt from automated stale handling.and removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jan 13, 2023 @jasnell Is this actionable, though?
Buffer.from(abv)has well-defined semantics right now (even if those include data truncation – it matchesUint8Array.from()in that regard, afaict).Reacted by Ben NoordhuisIt doesn't need to be
Buffer.from(abv)exactly. It can easily be another variation,Buffer.fromTypedArrayor such (I'm horrible with naming so other suggestions are welcome)Reacted by Livia MedeirosYeah, we could do that. It’s probably worth thinking about the name – it should reflect that it creates the buffer from the underlying memory of a TypedArray rather than its contents – and it’s probably still worth thinking about whether this really makes sense to address in Node.js itself (the fact that writing
new Uint8Array(typedArray.buffer, typedArray.byteOffset, typedArray.byteLength)is verbose and repetitive isn’t really a Node.js-specific thing).Agreed with idea of separate method; its existence by itself would also imply that
Buffer.from(abv)does something different.- added a commit that references this issue
on Feb 25, 2023 - added 2 commits that reference this issue
on Mar 13, 2023 - added a commit that references this issue
on Apr 11, 2023 - added a commit that references this issue
on May 22, 2026
What is the problem this feature will solve?
Buffer.from()has many different forms, includingBuffer.from(arrayBuffer[, byteOffset[, length]])andBuffer.from(buffer).However,
Buffer.from(abv)does not exist. Depending on exact input, trying to call it with such objects results in false positives, data truncation, data corruption (e.g.double->unsigned char), thrownTypeErrors and empty buffers.Creating
BufferfromArrayBufferView's data in userland is extremely error-prone becauseBuffer.from(arrayBuffer)doesn't copy the data.What is the feature you are proposing to solve the problem?
Adjust
Buffer.from(buffer)to accept not onlyBufferandUint8Arraybut anyArrayBufferViewor at least anyTypedArray.What alternatives have you considered?
Deprecation and removal of
Bufferfrom core into userspace module, with prior porting all core APIs to nativeUint8Array/TypedArray/ArrayBufferViews.