Skip to content
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

Multiple Evaluations of the Target of Byte and Dynamic Array Assignments #4071

Open
ritzdorf opened this issue Apr 25, 2024 · 2 comments
Open

Comments

@ritzdorf
Copy link
Contributor

ritzdorf commented Apr 25, 2024

Version Information

  • vyper Version (output of vyper --version OR linkable commit hash vyperlang/vyper@): b43ffac

Issue Description

Multiple evaluations of the target of byte and dynamic array assignments
have been described in issue
3514. However, this
issue was incomplete since it would only show the case where the complex
expression being evaluated twice is caught by the compiler's "non-unique
symbol" sanity check. However, it is possible to have a complex
expression evaluated twice without the compiler crashing by using
builtins like raw_call or the create_ class or .pop() on a
non-storage array.

Note that this issue has been partially mitigated by
3835 given that
builtins like raw_call and the create_ class are now emitting unique
symbols, however, this is not yet the case for .pop() when the array
is not in storage.

POC

The following code will compile successfully, and x.pop() will be
performed twice:

d:DynArray[DynArray[uint256,1],1]
addr:address
@external
def foo() -> DynArray[uint256, 2]:
    self.d = [[0]]
    x:DynArray[uint256, 2] = [0,0]
    self.d[x.pop()] = [1]
    return x # return [] instead of [0]
@ritzdorf
Copy link
Contributor Author

We also found an example using a HashMap now:

#@version 0.4.0.rc3
m: HashMap[uint256, String[33]]

@external
def foo(a: address):
    self.m[len(raw_call(a, msg.data, max_outsize=32))] = "Hello world"

fails to compile with

AssertionError: non-unique symbols {'raw_call_builtin102'}

@charles-cooper
Copy link
Member

addressed in #4030

@cyberthirst cyberthirst transferred this issue from another repository May 31, 2024
@charles-cooper charles-cooper transferred this issue from another repository May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants