no2chem
First conversion sometimes returns array with all zeros.
Second conversion and on does not seem to have this issue, but the very first conversion, depending on buffer size and number size returns an array with [0,0,0,0,...,0].
Thanks for the report, @xgovern
Could you provide an example where you're seeing this conversion issue?
//Code var n = 115792089237316195423570985008687907853269984666751n; console.log(n); console.log(toBufferLE(n,25)); //First one all zero console.log(toBufferLE(n,25)); //Second and on works fine.
//Console Log 115792089237316195423570985008687907853269984666751n <Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> <Buffer 7f e4 f8 24 e5 3e 9a aa 67 32 51 af 3b 24 3f f0 c8 db 68 3a 4f 00 00 00 00>
Node v10.13.0, by the way.
What I do is just do a simple conversion at the top import section to avoid the issue.
//Code const toBufferLE = require('bigint-buffer').toBufferLE; toBufferLE(1n,1); //DO NOT REMOVE, somehow the first call returns a null buffer array;
Hm, interesting. I haven't been able to replicate it just yet, even with 10.13.0, but I'll run some further tests to see.
I seem to recall having an issue with N-API and napi_get_buffer_info and some point in time, perhaps this is a related race condition.
Quick temp fix may be to run "toBufferLE(1n,1); toBufferBE(1n,1);" after module definition in the package itself.
I'm having the same issue. It's reproducible on glitch https://glitch.com/edit/#!/remix/bigint-buffer-bug. Seems to be fine with byte lengths that are multiples of 8
