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

No length check on bytes and string arrays #1840

Closed
iamdefinitelyahuman opened this issue Feb 3, 2020 · 1 comment · Fixed by #2076
Closed

No length check on bytes and string arrays #1840

iamdefinitelyahuman opened this issue Feb 3, 2020 · 1 comment · Fixed by #2076
Labels
bug Bug that shouldn't change language semantics when fixed.

Comments

@iamdefinitelyahuman
Copy link
Contributor

Version Information

  • vyper Version (output of vyper --version): 0.1.0b16
  • OS: linux
  • Python: 3.8

What's your issue about?

When a contract expects to receive a fixed length bytes or string array, there is no check on the length of the received data. In the following example, calling Bar.bar(Foo.address) returns b"foobar".

Contract Foo:

@public
def foo() -> bytes[6]:
    return b"foobar"

Contract Bar:

contract Foo:
    def foo() -> bytes[3]: constant

a: bytes[3]

@public
def bar(_addr: address) -> bytes[3]:
    self.a = Foo(_addr).foo()
    return self.a

This is an issue because Vyper does not allow dynamic arrays but Solidity does. If a Vyper contract is interacting with a Solidity contract that returns bytes or string it must give an upper bound on the expected bytes length.

How can it be fixed?

Check the length of the returned data when receiving a bytes or string array. If the length exceeds the given upper bound, truncate it.

@iamdefinitelyahuman
Copy link
Contributor Author

Possibly related to #1602

@fubuloubu fubuloubu added the bug Bug that shouldn't change language semantics when fixed. label Feb 3, 2020
@iamdefinitelyahuman iamdefinitelyahuman added this to the v0.2.0 Release milestone Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug that shouldn't change language semantics when fixed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants