Issues decoding an Opensea `atomicMatch_` function call about headlong HOT 6 CLOSED

The original intent was to fail fast if any potential data corruption was detected, but that's only useful for certain use cases. If anyone finds this behavior useful they can fork the code and add the check back in.

I will see about releasing this change soon.

Thanks a ton, Evan!

from headlong.

New release:

https://github.com/esaulpaugh/headlong/releases/tag/v6.3.0
https://repo1.maven.org/maven2/com/esaulpaugh/headlong/6.3.0/

from headlong.

Data is from transaction 0x1fc5750f695708ea56d61ef204dfe6385414d03f0d0496d6bdc50c24813b1881, trace address 1, 1, 0, 3, 2, 4 on the ethereum mainnet by the way!

from headlong.

If you comment out the line throwing the exception, does it decode correctly? Meaning, can you tell if the resulting data is malformed in any way?

from headlong.

The data looks alright to me.

It looks like they are reusing a 32-byte portion of a previous element's data (index 5) to act as the array length for a later element (an empty array at index 8) because it is all zeros.

I knew such things were possible, but I wanted to see it in the wild before I allowed it.

I think I will just allow all backwards jumps.

from headlong.

The original intent was to fail fast if any potential data corruption was detected, but that's only useful for certain use cases. If anyone finds this behavior useful they can fork the code and add the check back in.

I will see about releasing this change soon.

from headlong.