Skip to content

stream: support ArrayBufferView in Utf8Stream write() buffer mode - #65301

Closed
agape1225 wants to merge 1 commit into
nodejs:mainfrom
agape1225:lib-utf8-stream-arraybufferview-support
Closed

agape1225 wants to merge 1 commit into
nodejs:mainfrom
agape1225:lib-utf8-stream-arraybufferview-support

Conversation

@agape1225

Copy link
Copy Markdown
Contributor

Utf8Stream#write() in 'buffer' content mode only accepted Buffer instances, even though the underlying implementation only needs byte-addressable data. This accepts any ArrayBufferView (TypedArray, DataView) and reinterprets it as a Buffer over the same bytes (without copying), so callers no longer need to wrap other typed arrays in Buffer.from() themselves.

Views are normalized to a Buffer at the single entry point (#writeBuffer), using byteOffset/byteLength rather than the view's element-count length, so that internal length bookkeeping used by mergeBuf()/Buffer.concat() and the write-release logic keeps operating on real byte counts. This mirrors the existing pattern in zlibBuffer() (lib/zlib.js).

Utf8Stream#write() in 'buffer' content mode only accepted Buffer
instances, even though the underlying implementation only needs
byte-addressable data. This accepts any ArrayBufferView (TypedArray,
DataView) and reinterprets it as a Buffer over the same bytes
(without copying), so callers no longer need to wrap other typed
arrays in Buffer.from() themselves.

Views are normalized to a Buffer at the single entry point
(#writeBuffer), using byteOffset/byteLength rather than the view's
element-count length, so that internal length bookkeeping used by
mergeBuf()/Buffer.concat() and the write-release logic keeps
operating on real byte counts. This mirrors the existing pattern in
zlibBuffer() (lib/zlib.js).

Signed-off-by: agape1225 <49804691+agape1225@users.noreply.github.com>
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/streams

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. stream Issues and PRs related to Node.js streams. labels Aug 15, 2026
@codecov

codecov Bot commented Aug 15, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.32%. Comparing base (673cdef) to head (c15c1bc).
⚠️ Report is 886 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #65301      +/-   ##
==========================================
- Coverage   90.32%   90.32%   -0.01%     
==========================================
  Files         760      751       -9     
  Lines      248553   250244    +1691     
  Branches    46910    47298     +388     
==========================================
+ Hits       224510   226026    +1516     
- Misses      15462    15577     +115     
- Partials     8581     8641      +60     
Files with missing lines Coverage Δ
lib/internal/streams/fast-utf8-stream.js 81.33% <100.00%> (+0.50%) ⬆️

... and 104 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

daeyeon pushed a commit to ossca-node/board that referenced this pull request Aug 19, 2026
@daeyeon daeyeon added the request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. label Sep 21, 2026
@github-actions github-actions Bot removed the request-ci Add this label to start a Jenkins CI on a PR. Only starts once the PR has an approving review. label Sep 21, 2026
@nodejs-github-bot

This comment was marked as outdated.

@panva panva added author ready PRs with CI started, the required approvals, and no outstanding review comments. resume-ci Add this label to resume the latest eligible Jenkins CI run on a PR with an approving review. labels Sep 25, 2026
@github-actions github-actions Bot added resume-ci-failed Resuming CI with the resume-ci label failed and requires manual intervention. and removed resume-ci Add this label to resume the latest eligible Jenkins CI run on a PR with an approving review. labels Sep 25, 2026
@github-actions

This comment was marked as outdated.

@panva panva removed the resume-ci-failed Resuming CI with the resume-ci label failed and requires manual intervention. label Sep 25, 2026
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

@mcollina mcollina left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@panva panva added the resume-ci Add this label to resume the latest eligible Jenkins CI run on a PR with an approving review. label Sep 25, 2026
@github-actions github-actions Bot removed the resume-ci Add this label to resume the latest eligible Jenkins CI run on a PR with an approving review. label Sep 25, 2026
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

panva pushed a commit that referenced this pull request Sep 25, 2026
Utf8Stream#write() in 'buffer' content mode only accepted Buffer
instances, even though the underlying implementation only needs
byte-addressable data. This accepts any ArrayBufferView (TypedArray,
DataView) and reinterprets it as a Buffer over the same bytes
(without copying), so callers no longer need to wrap other typed
arrays in Buffer.from() themselves.

Views are normalized to a Buffer at the single entry point
(#writeBuffer), using byteOffset/byteLength rather than the view's
element-count length, so that internal length bookkeeping used by
mergeBuf()/Buffer.concat() and the write-release logic keeps
operating on real byte counts. This mirrors the existing pattern in
zlibBuffer() (lib/zlib.js).

Signed-off-by: agape1225 <49804691+agape1225@users.noreply.github.com>
PR-URL: #65301
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
@panva

panva commented Sep 25, 2026

Copy link
Copy Markdown
Member

Landed in 118f2a1

@panva panva closed this Sep 25, 2026
aduh95 pushed a commit that referenced this pull request Sep 27, 2026
Utf8Stream#write() in 'buffer' content mode only accepted Buffer
instances, even though the underlying implementation only needs
byte-addressable data. This accepts any ArrayBufferView (TypedArray,
DataView) and reinterprets it as a Buffer over the same bytes
(without copying), so callers no longer need to wrap other typed
arrays in Buffer.from() themselves.

Views are normalized to a Buffer at the single entry point
(#writeBuffer), using byteOffset/byteLength rather than the view's
element-count length, so that internal length bookkeeping used by
mergeBuf()/Buffer.concat() and the write-release logic keeps
operating on real byte counts. This mirrors the existing pattern in
zlibBuffer() (lib/zlib.js).

Signed-off-by: agape1225 <49804691+agape1225@users.noreply.github.com>
PR-URL: #65301
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
HoonDongKang pushed a commit to HoonDongKang/node that referenced this pull request Sep 28, 2026
Utf8Stream#write() in 'buffer' content mode only accepted Buffer
instances, even though the underlying implementation only needs
byte-addressable data. This accepts any ArrayBufferView (TypedArray,
DataView) and reinterprets it as a Buffer over the same bytes
(without copying), so callers no longer need to wrap other typed
arrays in Buffer.from() themselves.

Views are normalized to a Buffer at the single entry point
(#writeBuffer), using byteOffset/byteLength rather than the view's
element-count length, so that internal length bookkeeping used by
mergeBuf()/Buffer.concat() and the write-release logic keeps
operating on real byte counts. This mirrors the existing pattern in
zlibBuffer() (lib/zlib.js).

Signed-off-by: agape1225 <49804691+agape1225@users.noreply.github.com>
PR-URL: nodejs#65301
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
aduh95 pushed a commit that referenced this pull request Sep 28, 2026
Utf8Stream#write() in 'buffer' content mode only accepted Buffer
instances, even though the underlying implementation only needs
byte-addressable data. This accepts any ArrayBufferView (TypedArray,
DataView) and reinterprets it as a Buffer over the same bytes
(without copying), so callers no longer need to wrap other typed
arrays in Buffer.from() themselves.

Views are normalized to a Buffer at the single entry point
(#writeBuffer), using byteOffset/byteLength rather than the view's
element-count length, so that internal length bookkeeping used by
mergeBuf()/Buffer.concat() and the write-release logic keeps
operating on real byte counts. This mirrors the existing pattern in
zlibBuffer() (lib/zlib.js).

Signed-off-by: agape1225 <49804691+agape1225@users.noreply.github.com>
PR-URL: #65301
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author ready PRs with CI started, the required approvals, and no outstanding review comments. needs-ci PRs that need a full CI run. stream Issues and PRs related to Node.js streams.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants