no2chem / bigint-buffer

💪🔢 bigint-buffer: Buffer Utilities for TC39 BigInt Proposal
Apache License 2.0
54 stars 11 forks source link

First conversion sometimes returns array with all zeros. #12

Open xgovern opened 5 years ago

xgovern commented 5 years ago

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

no2chem commented 5 years ago

Thanks for the report, @xgovern

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

xgovern commented 5 years ago

//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 commented 5 years ago

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;

no2chem commented 5 years ago

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 commented 5 years ago

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

jrawsthorne commented 5 years ago

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