Repository navigation
feature: support initializing Buffer from an ArrayBuffer #106
Description
Activity
Curious: would this copy the memory represented by the
ArrayBuffer, or act as a view onto it?@chrisdickinson It should behave the same way as
new Buffer(buffer)i.e. copy, but the latter is impossible anyway37 remaining items
Fixed by 197ba00.
- added 9 commits that reference this issue
on Jul 22, 2015 I propose we make the
Bufferconstructor also acceptArrayBuffer.Currently this is what happens:
var u = new Uint8Array([1, 2, 3, 4]); var ab = u.buffer; var b = new Buffer(ab); console.log(b); // <Buffer >
This is what should happen:
console.log(b); // <Buffer 01 02 03 04>
When writing isomorphic code (i.e. code that runs on the server and in the browser), it's often the case that you'll get an
ArrayBufferfrom a DOM API (xhr, websockets, webrtc, etc.) and need to convert it to aBufferto work with modules in the npm ecosystem. Users often expect thatnew Buffer(arraybuffer)will work and they open issues when it doesn't.We have the
buffernpm module which gives us the sameBufferAPI in the browser (and is used by browserify), however it tracks the node.js/io.js buffer exactly, so we can't add support fornew Buffer(arraybuffer)unless core does too.I know the
Bufferconstructor already takes a million different argument types, so it couldn't hurt to add one more, right? Curious to see what the community thinks about this. If there's interest, I can send a PR.
I propose we make the
Bufferconstructor also acceptArrayBuffer.Currently this is what happens:
This is what should happen:
When writing isomorphic code (i.e. code that runs on the server and in the browser), it's often the case that you'll get an
ArrayBufferfrom a DOM API (xhr, websockets, webrtc, etc.) and need to convert it to aBufferto work with modules in the npm ecosystem. Users often expect thatnew Buffer(arraybuffer)will work and they open issues when it doesn't.We have the
buffernpm module which gives us the sameBufferAPI in the browser (and is used by browserify), however it tracks the node.js/io.js buffer exactly, so we can't add support fornew Buffer(arraybuffer)unless core does too.I know the
Bufferconstructor already takes a million different argument types, so it couldn't hurt to add one more, right? Curious to see what the community thinks about this. If there's interest, I can send a PR.