Use returndatacopy for cross-contract calls

[axic]

This will enable passing dynamic (bytes, string, variable length arrays, structs, etc.) data between calls.

For passing structs the new ABI encoder/decoder must be enabled - preferably by the time returndatacopy is enabled, the ABI rewrite will be mature enough to be on by default.

A related issue is #434 which introduces a new low-level call method which returns the raw bytes using returndatacopy.

The main risk here is that it makes contracts incompatible with pre-Byzantium EVMs.

[axic]

As a short term solution there could be annotation for functions to mark they are using the new ABI encoder. In that case the compiler could use returndatacopy.

[axic]

Proposal in #1117 would allow these features to be turned on/off.

[fulldecent]

Can you please provide us more details here.

• Is this issue "accepted"?
• It is committed that a change will be made?
• Is there a target version?

I am working on ERC-721 (ethereum/EIPs#841 (comment)). Could you please take a quick look at ERC721Enumerable. Am I doing it right? Should we delay this standard to wait for this issue?

[chriseth]

We are currently working on this. The main problem is that the old ABI decoder does not perform bounds checking and thus it would be possible for a malicious called contract to return data that can interfere with existing data in memory (read-only).

Since we are not yet 100% confident with the new ABI decoder (which does bounds checking), it might take a while until this is enabled by default.

[chriseth]

Actually thinking about this a little more, the old ABI decoder does not support multi-dimensional arrays or structs anyway, so the bounds checking would be a lot simpler.

[fulldecent]

Thank you for clarifying.

[fulldecent]

Adding notes here for people designing interfaces (originally discussed in solidity-dev).

Test case

pragma solidity ^0.4.20;

contract Items {
    uint256[] public oddNumbers;
    
    function Items() public {
        oddNumbers.push(1);
    }
    
    function extendSequence() external {
        uint256 next = oddNumbers[oddNumbers.length-1] + 2;
        require(next >= oddNumbers[oddNumbers.length-1]);
        oddNumbers.push(next);
    }
    
    function oddNumbersLength() external view returns (uint256) {
        return oddNumbers.length;
    }
    
    function oddNumbersAll() external view returns (uint256[]) {
        return oddNumbers;
    }
}

This exposes two interfaces for interrogating oddNumbers:

Piecemeal

function oddNumbers(uint256 index) external view returns (uint256); // Implicitly defined;
function oddNumbersLength() external view returns (uint256);

All-at-once

function oddNumbersAll() external view returns (uint256[]);

Discussion

The piecemeal approach is guaranteed to always work. But the all-at-once approach will fail for on-blockchain calls after the array reaches a certain length. This is because memory is copied, it is not mmaped.

If we live in a world where we see:

uint a;
uint b;
uint total = a + b;
require(total > a);

then I think it is important to make the above stipulation.

[beether]

I was looking for this exact feature and found it implemented 8 hours ago. Awesome work. Looking forward to the nightly build!

@fulldecent Spot on with the Piecemeal approach. Not exposing an indexed getter() could be a security risk. Is it possible to have an compiler warning for views returning dynamic arrays-of-arrays that the response is not always guaranteed to work?

[fulldecent]

@beether The compiler will not check for that because it is too difficult and requires conventions.

A new new SALOAD instruction (storage load from arbitrary account) would solve this. Then you could do:

pragma solidity ^0.4.21;

contract Array {
    uint[] public a;
}

contract Inspector {
    function getLength(Array _addr) external view returns (uint){
        return _addr.a.length;
    }

    function getIndex(Array _addr, uint _index) external view returns (uint){
        return _addr.a(_index);
    }
}

My idea here does not have consensus. And it is a breaking change to a fundamental concept (the implicit functions) -- it would not be accepted.

[beether]

@fulldecent Couldn't the compiler warn anytime a view returns arrays-of-arrays? It's similar to an infinite gas warning.