You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While we were confident that the fuzz diff testing were allowing us to dev fast and accuratly, we faced a significant number of bugs while finalizing the state transition functions. Amongst them:
careless casting = go from one internalXXXStruct to another type NewType(prev.valu/e) caused a lot of issues related especially to endianess
verbose type creation and update = hard to understand the core logic of a function when 50% of the code is boilerplate
What
Remove this two issues
no more cast (either with the actual keyword, or with the pattern above mentioned) outside of a well scope util
modifier for types so that what can just trie_get in one line (example)
How
Do not share internal struct if they are not the same underlying data (e.g. Uint256 used by Hash32, U256, etc.)
List all such cases and create ad-hoc uils, e.g.
U256_to_be_bytes
U256_into_Hash32
wherever there is a cast, think about a dedicated util/"method" to encapsulate it so that it's well delimited
The content you are editing has changed. Please copy your edits and refresh the page.
Why
While we were confident that the fuzz diff testing were allowing us to dev fast and accuratly, we faced a significant number of bugs while finalizing the state transition functions. Amongst them:
XXXStruct
to another typeNewType(prev.valu/e)
caused a lot of issues related especially to endianessWhat
Remove this two issues
cast
(either with the actual keyword, or with the pattern above mentioned) outside of a well scope utiltrie_get
in one line (example)How
cast
, think about a dedicated util/"method" to encapsulate it so that it's well delimitedTasks
cast
into dedicated functions #801The text was updated successfully, but these errors were encountered: