fixed bitlen calc

[dovgopoly]

Hi, I noticed a potential bug in the _add function when recalculating bitlen. Consider a scenario where the most significant word is already 1 and remains unchanged. In this case, the algorithm incorrectly calculates the result bitlen.

stack.add(
        "0x010000000000000000000000000000000000000000000000000000000000000001",
        "0x01"
);

The result bitlen is 258 but it's expected to be 257.

[jdbertron]

That should be fairly simple to illustrate with an example, right ?

[dovgopoly]

Say we have two normalized big numbers a = [a2, a1] and b = [b1].
a1 = 0000000000000000000000000000000000000000000000000000000000000001
a2 = 0000000000000000000000000000000000000000000000000000000000000001
b1 = 0000000000000000000000000000000000000000000000000000000000000001
The result would be r = [r2, r1] = [a2, a1 + b1].
r1 = 0000000000000000000000000000000000000000000000000000000000000002
r2 = 0000000000000000000000000000000000000000000000000000000000000001

Here you set the most significant word of the result to 1 if an overflow occurs. But in some cases msword equals 1 even without an overflow, as shown in the example (r2). This is why I suggest using carry instead of msword to determine whether to increase the bit length.

[riordant]

Hi, thanks for your contribution!
would you mind adding a unit test (BigNumbers.t.sol) implementing this example?

[dovgopoly]

@riordant Done

[riordant]

@dovgopoly merged :)