Value change after uint256.FromBig and then ToBig

[Requiemu]

Negative value change after uint256.FromBig and then ToBig:

func TestReverse(t *testing.T) {
	a, _ := big.NewInt(0).SetString("-1", 10)
	u, _ := uint256.FromBig(a)
	areverse := u.ToBig()
	fmt.Println(areverse, areverse.Sign(), a.Sign())
	// areverse:  115792089237316195423570985008687907853269984665640564039457584007913129639935 1 -1
}

[holiman]

The behaviour is pretty reasonable, IMO.

func TestReverse(t *testing.T) {
	// A small negative integer
	{
		a := big.NewInt(-1)
		u, overflow := FromBig(a)
		areverse := u.ToBig()
		fmt.Printf("%x (%v) => %x (%v), overflow: %v\n", a, a.Sign(), areverse, areverse.Sign(), overflow)
	}
	// A >256 bit negative integer
	{
		a, _ := big.NewInt(0).SetString("-11ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", 16)
		u, overflow := FromBig(a)
		areverse := u.ToBig()
		fmt.Printf("%x (%v) => %x (%v), overflow: %v\n", a, a.Sign(), areverse, areverse.Sign(), overflow)
	}
}

When doing -1, the conversion does not report overflow, but instead interprets it as the -1 wraparound. The fact that you cannot go back to a signed big.Int after uint256 (unsigned 256-bit integer) is kind of to be expected, IMO.

-1 (-1) => ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (1), overflow: false

For the second case, the FromBig does report that an overflow happens.

-11ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (-1) => 1 (1), overflow: true

I don't see how the behaviour should change -- can't get around the fact that some 'clipping' will occur when going from a 'signed space' to 'unsigned space' and back again?

[chfast]

Can you always report overflow in the BigInt is negative?

[holiman]

I thought about that. For one thing, it's a bit of a breaking change.

For another, the first case is different from the second case, since -1 is somewhat "within bounds" - the 256 bit complementary can be represented ok. If we treat it as "out of bounds", then the two cases become indistinguishable.

[AlexanderMint]

@holiman Please tell me if this behavior is expected, I always get a negative result

	amount := uint256.NewInt(0)

	if ok := amount.SetFromBig(big.NewInt(9)); !ok {
		fmt.Println("9 !ok")
	}
	fmt.Println("amount:", amount)

	amount = uint256.NewInt(0)
	if ok := amount.SetFromBig(big.NewInt(-9)); !ok {
		fmt.Println("-9 !ok")
	}
	fmt.Println("amount:", amount)

result:

9 !ok
amount: 9
-9 !ok
amount: 115792089237316195423570985008687907853269984665640564039457584007913129639927

[holiman]

amount.SetFromBig does not return ok, it returns overflow . So what you're seeing is

9 did not overflow
amount: 9
-9 did not overflow
amount: 115792089237316195423570985008687907853269984665640564039457584007913129639927

This is the exact same case as the original report, except with -9 instead of -1. I see that it's confusing, but I don't see any obvious way to improve it. I'll leave this ticket open, so people can find it easier.

[linhbkhn95]

@holiman @Requiemu
I am building the package int256 which wraps uint256. It will support functions like big.Int.
https://github.com/linhbkhn95/int256

[holiman]

@linhbkhn95 Interesting!

Though, is it 256 ? Since you're representing a sign and a full 256-bit value, the minimum representation of it is 257 bits?

Also, I'm curious how you will define the semantics regarding boolean operations (ignore sign?)

Also, I think there are cases, like here: https://github.com/linhbkhn95/int256/blob/master/int256.go#L260 , where the caller can wind up with an Int which is -0, negative zero. And you either have to handle that in other places: check for it in all the various methods (like Cmp, negative zero vs zero should be equal), or you have to prevent it from ever happening by normalizing it anywhere an Int is mutated.

Anyway, good luck, seems like a fun project!

[linhbkhn95]

@holiman you are right, I am building it and trying to test it in my internal services. I will improve and finalize it ASAP.

[ngotchac]

As the main struct is called Int, I actually thought it was handling signed integers. Re-reading the docs makes it clear, though.