3

Is there any advantage of using inline assembly call over address.call?

For example 

// address addr // uint value // bytes memory data // using inline assembly assembly { call(gas, addr, value, add(data, 0x20), mload(data), mload(0x40), 0) } // using address.call addr.call.value(value)(data)

I am looking at the code for Gnosis multisig wallet and wondered why they were using assembly call instead of address.call

Improve this question

1 Answer 1

Reset to default
2

Well, it's pretty obvious when looking into the set of input arguments passed in each case.

For the non-assembly call, you pass:

  • Destination address (addr)
  • Amount of ether (value)
  • Executable code (data)

For the assembly call, you pass:

  • Number of gas units
  • Destination address
  • Amount of ether
  • Executable code (data buffer + data length)
  • Output address (data buffer + data length)

So with the assembly call, you can also:

  1. Configure the gas
  2. Obtain the output

Edit(sea212): In this context, for solc == 0.4.x: By adding .gas(gas) you can also specify the number of gas units in non-assembly call. So the main advantage in using the assembly call is that you can obtain the output.

Improve this answer
6
  • 1
    You can also obtain the output with the high-level call: <address>.call(bytes memory) returns (bool, bytes memory): issue low-level CALL with the given payload, returns success condition and return data, forwards all available gas, adjustable Commented Mar 3, 2020 at 11:47
  • @sea212: The question is about address.call.value, not address.call. Commented Mar 3, 2020 at 11:54
  • They are equivalent, except that you pass ether to a payable function. address.call.value(val)(data) is the Solidity <0.6.0 version of Solidity >=0.6.0 address.call{value: val}(data). In both cases they use the high level call I posted in the first comment and therefore in both cases they return a bool indicating the success of the execution and bytes containing the return data. You can test this in remix. What would be the point of a general call that does not offer the possibility to inspect the results? Commented Mar 3, 2020 at 12:21
  • 1
    @sea212: Of course, but the point of the question was to ask about any possible advantage in using assembly call over Solidity address.call.value, which is what I was trying to answer here. Also, please note that the contract in question was implemented in Solidity 0.4, so any extension of address.call.value in later versions is not really relevant in this context (i.e., should not be considered as part of the answer IMO). Commented Mar 3, 2020 at 12:32
  • 1
    I checked the solidity docs for Solidity 0.4.15 (which they used when they created the contract) and to my astonishment, it was indeed not possible to return the output data at that time. Nevertheless it was possible to configure the supplied gas by appending .gas(gas), e.g. address.call.value(value).gas(gas)(data). Quote: call returns a boolean indicating whether the invoked function terminated (true) or caused an EVM exception (false). It is not possible to access the actual data returned (for this we would need to know the encoding and size in advance). Commented Mar 3, 2020 at 12:40

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.