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

Disallow returning Vec (and any raw_ptr) from a contract to another contract #3397

Open
mohammadfawaz opened this issue Nov 21, 2022 · 2 comments
Labels
compiler: ui Mostly compiler messages enhancement New feature or request P: critical Should be looked at before anything else

Comments

@mohammadfawaz
Copy link
Contributor

Returning a Vec from one contract to another should be disallowed because the pointer from the called contract is not valid in the caller contract. The same check that we have that disallows returning raw_ptr from scripts should also be used in this case.

@mohammadfawaz mohammadfawaz added enhancement New feature or request P: critical Should be looked at before anything else compiler: ui Mostly compiler messages labels Nov 21, 2022
@mohammadfawaz mohammadfawaz changed the title Disallow returning Vec from a contract to another contract Disallow returning Vec (and any raw_ptr) from a contract to another contract Nov 21, 2022
@mohammadfawaz
Copy link
Contributor Author

mohammadfawaz commented Dec 2, 2022

Here's a simple example:

library with an ABI:

library external_abi;

abi MyAbi {
    fn foo() -> Vec <u64>;
}

Contract:

contract;

dep external_abi;

use external_abi::MyAbi;

abi MyContract {
    fn bar();
}

impl MyContract for Contract {
    fn bar() {
        let caller = abi(MyAbi, 0x0000000000000000000000000000000000000000000000000000000000000000);

        let result:Vec<u64> = caller.foo(); // This should be an error
    }
}

The idea is going to be to return a slice instead.

@adlerjohn
Copy link
Contributor

Ackchyually you should be able to return a Vec from a contract! Since there is no deallocation, a returned pointer will still be valid. However, the caller will have to make sure the data pointed to remains valid by allocating space for the underlying data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler: ui Mostly compiler messages enhancement New feature or request P: critical Should be looked at before anything else
Projects
None yet
Development

No branches or pull requests

2 participants