New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-semantics-preserving refactoring for zero_pad()
#1610
Comments
FYI, for the loop terminating condition, the original code uses |
I'm not sure the new code is incorrect, because |
@charles-cooper There is a counter example that The important thing is not |
Thanks @daejunpark - please see 033d7df |
Thank you for your patience in explaining this issue. For condition 2 I pushed 5469fae. |
@charles-cooper Awesome. Thanks! I'd like to compile the deposit contract to make sure that these changes produce the expected bytecode. How to pull your changes? (I cannot find it when |
@daejunpark I believe you can find it on my fork of vyper |
Thanks! (I didn't know that Github also shows the commits of forks.) The deposit contract IR generated by your |
@daejunpark I also added the analogous fixes to #1605 so it is semantically on par with my zero_pad branch. It does look a lot clearer to me since we can dispense with |
@daejunpark #1611 was released in beta-13. I want to get #1605 into beta-14, what is the process for checking that the eth2.0 deposit contract tests pass? |
@charles-cooper sorry for the delay in replying. If you meant the formal verification, I'll need to re-run the verification against the new compiler version. If you meant the regular testing, you can refer to: #1563 (comment) |
Version Information
vyper --version
): 0.1.0b12+commit.8663ac5What's your issue about?
(copied here from #1572 (review) for a better discussion)
The refactoring (09a8af7) made as part of PR #1572 does not preserve the original semantics.
This is the original code:
And this is the new code that replaces the above code entirely:
where the definition of
zero_pad()
is:In order for this refactoring to be semantics-preserving, the following two conditions need to be satisfied, but I have a counter-example that the first condition is not always met. I haven't found a counter-example for the second, but I'm not sure if it is always the case.
maxlen
is equal tonew_maxlen
._ceil32_end
is equal tonew_maxlen
.How can it be fixed?
To fix the first case, add back the
new_maxlen
computation:and pass
new_maxlen
tozero_pad()
, like:For the second case, either prove that the second condition is always met, or generalize
zero_pad()
to handle the case that the second condition is not met.The text was updated successfully, but these errors were encountered: