abigen incorrect uint32/big.Int bindings

[rusenask]

System information

Geth version: 1.3.6
OS & Version: OSX
Commit hash : 9e323d6

Expected behaviour

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".

Actual behaviour

When executing contract function from Go side - getting unmarshal error. Once I modify generated code myself (change types from []uint32 to []*big.Int) - everything works fine.
I could look at it myself if someone gave me directions where to look, thanks.

Steps to reproduce the behaviour

1. Create a contract that returns " returns( uint32 [] yourList) "
2. Create binding with abigen.
3. Execute that function.

Backtrace

abi: cannot unmarshal []*big.Int in to []uint32

[karalabe]

I remember an issue like this being fixed a while ago. I'm guessing it was also merged in on the 1.4.x branches. Perhaps you should update to 1.4.9 and see with that? Although if you're using Native DApps I assume you use some develop sources already as 1.3.6 didn't have them at all. Please update your geth sources and retry.

[rusenask]

Updated to

Geth
Version: 1.4.9-stable-b7e3dfc5
Protocol Versions: [63 62 61]
Network Id: 1
Go Version: go1.6
OS: darwin

Tried to recreate bindings - still the same problem, maybe it's because of uint32 and not uint? for uint I get correct big.Int

[tbocek]

I had the same issue (with current master) and I think I fixed it here:

https://github.com/tbocek/go-ethereum/commit/04c5fb69fa8ff9b8d3b898a3aba132e77ea4bee7
https://github.com/tbocek/go-ethereum/commit/04c5fb69fa8ff9b8d3b898a3aba132e77ea4bee7

@karalabe Can you check if that makes sense, and then I can submit a pull request

[tbocek]

Just upgraded to 1.5.x (current master) and still got the same isssue:

Failed to report temperatures: abi: cannot unmarshal []*big.Int in to []uint32. I'll submit a pull request

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.