Unexpected behavior for .buffer property of sliced Buffers

[jfirebaugh]

• Version: 6.1.0
• Platform: OS X
• Subsystem: Buffer

Since instances of Buffer purport to also be Uint8Array TypedArray instances, I'd expect both of the following to produce 8:

> new Buffer(16).slice(8).buffer.byteLength
8192
> new Uint8Array(16).slice(8).buffer.byteLength
8

The fact that the buffer property on a Buffer slice returns an ArrayBuffer viewing the entire Buffer -- 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.

[bnoordhuis]

Buffer objects may come from a shared memory pool and the documentation mentions that in several places, grep for 'pool'.

[jfirebaugh]

@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 buffer property on a Buffer slice depends on whether or not the backing store comes from the shared memory pool?

[addaleax]

@jfirebaugh Yes:

> Buffer.allocUnsafeSlow(16).slice(8).buffer.byteLength
16
> Buffer.allocUnsafe(16).slice(8).buffer.byteLength
8192

[jfirebaugh]

And for completeness, a third possibility:

> Buffer.alloc(16).slice(8).buffer.byteLength
16

Is this intended behavior for the buffer property of a Buffer slice, that it returns a result that's dependent on the original allocation method?

[bnoordhuis]

Yes. It's worked that way since node v0.3 or v0.4, although the property was called .parent back then.

[jfirebaugh]

Okay. Can you please document the buffer property, and mention that has different behavior than Uint8Array.prototype.buffer?

[vkurchatkin]

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
16

or

> new Uint8Array(16).subarray(0, 8).buffer.byteLength
16

[jfirebaugh]

@vkurchatkin It does have different behavior, as I demonstrated in the initial description. For a Uint8Array slice, buffer returns an ArrayBuffer reflecting the slice. (If you want, I'll dig up a standards reference for that.) For a Buffer slice, it does not -- based on the results, I assume it returns an ArrayBuffer reflecting 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.)

[jfirebaugh]

Ok, disregard the above comment. After reading some more, I can see that the difference in behavior is stemming from slice(), not from buffer.

[vkurchatkin]

closing then, slice behaviour is well documented