Do not use uint in consensus datastructures.

[MicahZoltu]

https://github.com/ethereum/go-ethereum/blob/master/core/types/receipt.go#L49

https://golang.org/pkg/builtin/#uint

uint is an unsigned integer type that is at least 32 bits in size. It is a distinct type, however, and not an alias for, say, uint32.

uint in golang isn't guaranteed to be exactly 32-bits, so it should not be used in a datastructure that needs to be serialized or hashed since future compilers may use uint64 under the hood.

[karalabe]

It's actually uint64 on amd64 and uint32 on 386. That said, I agree.

[karalabe]

Hmm, however, all consensus data is encoded into RLP, which truncates any integer to it's minimal size. So uint64(15), will still be serialized as a single byte of 0x0f.

[MicahZoltu]

Ah, if the serialization scheme encodes the same number in both uint32 and uint64 to the same encoded byte array then this isn't a big problem. I still recommend being explicit rather than relying on this fact as a style/problem-avoidance scheme, but that is much less critical than I originally thought.

[karalabe]

I concur that it's generally a good idea to keep protocol fields as strict as possible.

[rjl493456442]

@MicahZoltu Actually there is a convert function to fill PostStateOrStatus field with receiptStatusFailedRLP = []byte{}, receiptStatusSuccessfulRLP = []byte{0x01} or PostState before the byzantium fork.

But for more strict field definition purpose, i will submit a PR to eliminate misleading.