buf.readUIntLE(offset, byteLength)
with byteLength > 6 to return BigInt
/cc @devsnek
i would be more comfortable with another method to give bigints (readBigUintLE(offset, byteLength)
)
@devsnek Separate methods for BigInt sound perfectly reasonable.
Oh man... I was just about to submit a new issue, when I thought I'd do one more search. Coulda got in big trouble :stuck_out_tongue_closed_eyes: I'll paste it here instead:
I see there was an attempt to add these methods a few years ago, but now that we have native BigInt
support, perhaps it's time to revisit this?
All the existing methods should probably be updated to accept BigInts, as it appears presently they do not:
โฏ node
> buf = Buffer.alloc(16)
<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
> buf.writeUInt32BE(10n,0)
TypeError: Cannot convert a BigInt value to a number
at writeU_Int32BE (internal/buffer.js:624:11)
at Buffer.writeUInt32BE (internal/buffer.js:638:10)
And then some new 64-bit variants would be nice ({read,write}[U]Int64{BE,LE}). I think they'd only take BigInt
s as we can't safely represent 64-bit integers with regular Number
s.
And then lastly, I think buf.writeUIntBE
and buf.writeUIntLE
should allow byteLength
s larger than 6 when given a BigInt
.
Separate methods for the BigInt versions might make more sense, now that you guys mention it. It would create less confusion around why the 64-bit versions don't accept Numbers.
I've implemented this using N-API: https://github.com/no2chem/bigint-buffer - but I feel that this should be a core part of the node Buffer API (and BigInt API).
Any news on this feature?
64-bit int support has arrived. I think we're still missing arbitrary precision support.
Amazing that JS does support BigInt('0b1010101010101011010101010101')
, who TF puts binary in string form like that, but not the obvious use case of reading a BigInt directly from a Buffer.
This code (BE) is quite some faster than BigInt(`0x${someBuffer.toString('hex')}`)
but still a native operator would be easier and faster
someBuffer.reduce((val, int) => (val << BigInt(8)) | BigInt(int), BigInt(0));
Most helpful comment
@devsnek Separate methods for BigInt sound perfectly reasonable.