Repository navigation
Unexpected behavior for .buffer property of sliced Buffers #6744
Description
Activity
Buffer objects may come from a shared memory pool and the documentation mentions that in several places, grep for 'pool'.
@bnoordhuis If there's a connection between any of the mentions of "pool" in the documentation, and the issue here, it's not clear to me. Are you implying that the behavior of the
bufferproperty on aBufferslice depends on whether or not the backing store comes from the shared memory pool?@jfirebaugh Yes:
> Buffer.allocUnsafeSlow(16).slice(8).buffer.byteLength 16 > Buffer.allocUnsafe(16).slice(8).buffer.byteLength 8192
And for completeness, a third possibility:
> Buffer.alloc(16).slice(8).buffer.byteLength 16Is this intended behavior for the
bufferproperty of aBufferslice, that it returns a result that's dependent on the original allocation method?Yes. It's worked that way since node v0.3 or v0.4, although the property was called
.parentback then.Okay. Can you please document the
bufferproperty, and mention that has different behavior thanUint8Array.prototype.buffer?mention that has different behavior than Uint8Array
Well, it's not, it's the same property. For example:
> new Uint8Array(new ArrayBuffer(16), 0, 8).buffer.byteLength 16or
> new Uint8Array(16).subarray(0, 8).buffer.byteLength 16@vkurchatkin It does have different behavior, as I demonstrated in the initial description. For a
Uint8Arrayslice,bufferreturns anArrayBufferreflecting the slice. (If you want, I'll dig up a standards reference for that.) For aBufferslice, it does not -- based on the results, I assume it returns anArrayBufferreflecting the unsliced backing store.> new Buffer(16).slice(8).buffer.byteLength 8192 > new Uint8Array(16).slice(8).buffer.byteLength 8(I personally don't think 8192 is a defensible result here, but if you've decided that's the desired behavior, fine -- I'm just asking that it be documented.)
Ok, disregard the above comment. After reading some more, I can see that the difference in behavior is stemming from
slice(), not frombuffer.closing then,
slicebehaviour is well documented
Since instances of
Bufferpurport to also beUint8ArrayTypedArray instances, I'd expect both of the following to produce8:The fact that the
bufferproperty on aBufferslice returns anArrayBufferviewing the entireBuffer-- rather than just the slice as I expected -- looks like a bug to me. However, there's the possibility that this falls under the category of "subtle incompatibilities with the TypedArray specification" that the documentation mentions. If that is the case, please explicitly state that in the documentation.