Skip to content

Commit

Permalink
Fix a typo
Browse files Browse the repository at this point in the history
  • Loading branch information
pirapira committed Nov 17, 2017
1 parent e3dff83 commit d08ccf4
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion EIPS/returndatacopy.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Note that this proposal also makes the EIP that proposes to allow to return data

## Specification

Add two new opcodes and amend the semantics of any opcode that creates a new call frame (like `CALL`, `CREATE`, `DELEGATECALL`, ...) called call-like opcodes in the following. It is assumed that the EVM (to be more specific: an EVM call frame) has a new internal buffer of variable size, called the return data buffer. This buffer is created empty for each new call frame. Upon executing any call-like opcode, the buffer is cleared (its size is set to zero). After executing a call-like opcode, the complete return data (or failure data, see EIP [206](https://github.com/ethereum/EIPs/pull/206)) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. As an exception, `CREATE` and `CREATE2` are considered to return the empty buffer in the success case and the failure data in the failure case. If the call-like opcode is executed but does not really instanciate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty.
Add two new opcodes and amend the semantics of any opcode that creates a new call frame (like `CALL`, `CREATE`, `DELEGATECALL`, ...) called call-like opcodes in the following. It is assumed that the EVM (to be more specific: an EVM call frame) has a new internal buffer of variable size, called the return data buffer. This buffer is created empty for each new call frame. Upon executing any call-like opcode, the buffer is cleared (its size is set to zero). After executing a call-like opcode, the complete return data (or failure data, see EIP [206](https://github.com/ethereum/EIPs/pull/206)) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. As an exception, `CREATE` and `CREATE2` are considered to return the empty buffer in the success case and the failure data in the failure case. If the call-like opcode is executed but does not really instantiate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty.

As an optimization, it is possible to share the return data buffer across call frames because only one will be non-empty at any time.

Expand Down

0 comments on commit d08ccf4

Please sign in to comment.