conversion: introduce 0-alloc IntoBig method#177
conversion: introduce 0-alloc IntoBig method#177holiman merged 2 commits intoholiman:masterfrom karalabe:alloc-free-to-big
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
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 |
|
|
||
| // IntoBig sets a provided big.Int to the value of z. | ||
| // Sets `nil` if z is nil (thus the double pointer). | ||
| func (z *Int) IntoBig(b **big.Int) { |
There was a problem hiding this comment.
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:
- panic on nil deref if
zis nil - Set the
bto zero ifzis nil
And then get rid of the **?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
**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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Fixes #176
TL;DR:
ToBigdoes 2x32 byte allocations. Once to create a new big.Int and a second time to seed the contents of the big.Int. This PR addsIntoBig(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: