Commit Graph
4 Commits
Author SHA1 Message Date
Thomas Bocek 1bd9769111 accounts/abi: fixed broken types slice testcases
Check for slice in type as well and adapted test case as arrays
also store its types.
2017-01-09 11:36:33 +02:00
tbocek fc213c873d accounts/abi: added testcase to unpack []uint32 2017-01-09 11:36:32 +02:00
Thomas Bocek 972f0bd3db accounts/abi: support custom int slice types
On solidity contract I have "uint32 []" type, when abigen creates Go
bindings - they are also "[]uint32" type on Go side. Even though it
looks like it should work - the actual type of the data coming from
the chain is of type " []*big.Int".

When executing contract function from Go side - getting unmarshal error:
abi: cannot unmarshal []*big.Int in to []uint32

The fix is to create array with the correct type

This fixed the issue reported in: https://github.com/ethereum/go-ethereum/issues/2802
2017-01-09 11:36:31 +02:00
Thomas Bocek 89c6c5bb85 accounts/abi: Negative numbers not properly converted in ABI encoding
When converting a negative number e.g., -2, the resulting ABI encoding
should look as follows:
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe.
However, since the check of the type is for an uint instead of an
int, it results in the following ABI encoding:
0101010101010101010101010101010101010101010101010101010101010102. The
Ethereum ABI
(https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI) says,
that signed integers are stored in two's complement which should be
of the form ffffff.... and not 01010101..... for e.g. -1. Thus, I
removed the type check in numbers.go as well as the function S256
as I don't think they are correct. Or maybe I'm missing something?
2016-06-06 14:27:15 +02:00