Potential discrepancy in error generation for some opcodes

[msooseth]

As per instructions.go in go-ethereum, the instructions CALLDATACOPY, CODECOPY, EXTCODECOPY, and RETURNDATACOPY may to do something other than what we do? In particular, they try to force the offset for these copy operations to be 64b and if they overflow, they set it to 0xffffffffffffffff, i.e. the largest 64b value and continue (and potentially fail later).

For go-ethereum behaviour see instructions.go line here: https://github.com/ethereum/go-ethereum/blob/master/core/vm/instructions.go#L307

[msooseth]

So for all these opcodes: CALLDATACOPY, CODECOPY, EXTCODECOPY

The spec says: For out of bound bytes, 0s will be copied.

But... the data offset is actually incorrect. It should not wrap around. It simply trucates it to maxW64 and then writes 0s.

Still can't trigger it but Tracing.hs now has a few test cases exercising CALLDATACOPY

[msooseth]

Nope, geth is basically incomplete, and that code is not meant to be executed with larger than 64b values, hence the roll-around. This issue is better tracked here: #401