Fix addition with negative int64_t

[cerg2010cerg2010]

Negative part wasn't always handled, so expressions like (1 << 256) - 1 behaved incorrectly.

The result of the subtraction contained 5 64-bit numbers, but only first one was correct, i.e. had 0xffff... value. Next 3 parts were all 0's, and the last one was 1.

The fix is simple - just add the negative part of the operand if it was negative initially.

Initial behavior was kinda like unsigned addition, but if (negA) check ruined everything anyways because of incorrect addition of negative part. There's possibly an additional overload needed to have correct unsigned behavior.

[tigertv]

Hi, @cerg2010cerg2010!
You are right. There is the trouble. It doesn't work correctly even with (1 << 64) - 1.
I will find out that. Thank you.

[tigertv]

@cerg2010cerg2010, Merged.
Have you seen something terrible else?

[cerg2010cerg2010]

@tigertv Thanks.

Yes, there's another problem with bitwise operations - see mekhovyyekulaki@27dae38
After the op amount of parts remains the same, so comparisons start to fail.

Also it would be better if there was an option to disable tests while importing the library, like that - mekhovyyekulaki@4dcf417
They get interferred with the project's tests which make the library less comfortable to use.

All this is implemented in my fork, I can try to split the changes and open the separate pull requests if you'd like.

[tigertv]

@cerg2010cerg2010, OK, make the separate pull requests.

Yes, there's another problem with bitwise operations - see mekhovyyekulaki@27dae38
After the op amount of parts remains the same, so comparisons start to fail.

Would you give a testcase?

Also it would be better if there was an option to disable tests while importing the library, like that - mekhovyyekulaki@4dcf417
They get interferred with the project's tests which make the library less comfortable to use.

No problem. If it's more useful, why not?