conversion: introduce 0-alloc IntoBig method

[karalabe]

Fixes #176

TL;DR: ToBig does 2x32 byte allocations. Once to create a new big.Int and a second time to seed the contents of the big.Int. This PR adds IntoBig (to avoid breaking the API) which takes an input big.Int, and if it has a large enough internal buffer, it will use that for conversion instead of reallocating.

If the big.Int is nil, it will be allocated (32 byte) and if it's not large enough, it's data space will be allocated (32 byte).

Bechmarks:

goos: darwin
goarch: arm64
pkg: github.com/holiman/uint256
BenchmarkToBig/1word-12         	35593915	        33.95 ns/op	      64 B/op	       2 allocs/op
BenchmarkToBig/2words-12        	35652079	        33.95 ns/op	      64 B/op	       2 allocs/op
BenchmarkToBig/3words-12        	36683552	        33.47 ns/op	      64 B/op	       2 allocs/op
BenchmarkToBig/4words-12        	36919052	        33.22 ns/op	      64 B/op	       2 allocs/op
BenchmarkIntoBig/1word-12       	341185051	         3.467 ns/op	       0 B/op	       0 allocs/op
BenchmarkIntoBig/2words-12      	375558397	         3.194 ns/op	       0 B/op	       0 allocs/op
BenchmarkIntoBig/3words-12      	460186147	         2.653 ns/op	       0 B/op	       0 allocs/op
BenchmarkIntoBig/4words-12      	511418574	         2.368 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/holiman/uint256	12.132s

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (75a5209) to head (2d03468).

Additional details and impacted files

@@            Coverage Diff            @@
##            master      #177   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            5         5           
  Lines         1640      1663   +23     
=========================================
+ Hits          1640      1663   +23     

[holiman]

I don't like to have a double-pointer in the API. It's not nice to work with, because it's so unusual.
I can be persuaded otherwise, but, why not just pick one of these options:

1. panic on nil deref if z is nil
2. Set the b to zero if z is nil

And then get rid of the **?

[karalabe]

Well, the purpose is to convert between uint256 and big.Int. If nil is a valid uint256 value, it we should be able to convert it to big.Int. IMO we''ll shoot ourselves in the foot with all the optional uint256 fields if we panic all of a sudden. Also converting an unset-optional into a set-0 seems bad.

[karalabe]

**big.Int is similar to *[] (i.e. slice pointer) FWIW. Maybe unusual to see a double pointer like that, but it's not a unique construct. You can definitely work around it by delegating nil checks to outer code, but then half the conversion happens inside the lib, but the other half (allocating/nilling the big.Int happens outside).

IMO the API "strageness" isn't that bad compared to having everyone become responsible for handling nil/non-nil in their code explicitly.

[karalabe]

Point in case, straight from the Go standard library: https://github.com/golang/go/blob/b8f83e22703ee23d49d95154449ce7066402d5c9/src/crypto/internal/boring/boring.go#L83

Converting big ints by placing them into an existing variable :)

[namiloh]

Ok!

[holiman]

But if b is nil, this will panic. Is that intentional? I guess it is, just want to double-check that's what we want

[karalabe]

Apart from sending in nil explicitly, there's no meaningful way you can end up with nil.

i.e. if you have a nil big.int pointer, you can still take it's address and it will be a non-nil pointer you can use to init the big.int. Since nobody's passing double pointers around in general for big.ints, you can't realistically end up with an accidental nil double pointer.

[holiman]

LGTM