First conversion sometimes returns array with all zeros.

[xGovern Team]

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].

[Michael Wei]

Thanks for the report, @xgovern

Could you provide an example where you're seeing this conversion issue?

[xGovern Team]

//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>

[xGovern Team]

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;

[Michael Wei]

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.

[xGovern Team]

Quick temp fix may be to run "toBufferLE(1n,1); toBufferBE(1n,1);"
after module definition in the package itself.

[Jake Rawsthorne]

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