Commit Graph

3 Commits

Author SHA1 Message Date
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
Jeffrey Wilcke 4880868c88 accounts/abi: fixed string and fixed size bytes packing 2016-04-28 12:41:47 +02:00
Jeffrey Wilcke 5127ec10cb accouns/abi: refactored ABI package
Refactored the abi package parsing and type handling. Relying mostly on
package reflect as opposed to most of our own type reflection. Our own
type reflection is still used however for cases such as Bytes and
FixedBytes (abi: bytes•).

This also inclused several fixes for slice handling of arbitrary and
fixed size for all supported types.

This also further removes implicit type casting such as assigning,
for example `[2]T{} = []T{1}` will fail, however `[2]T{} == []T{1, 2}`
(notice assigning *slice* to fixed size *array*). Assigning arrays to
slices will always succeed if they are of the same element type.

Incidentally also fixes #2379
2016-04-20 16:43:57 +02:00