diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/abi-spec.rst | 10 | ||||
| -rw-r--r-- | docs/contracts.rst | 40 |
2 files changed, 39 insertions, 11 deletions
diff --git a/docs/abi-spec.rst b/docs/abi-spec.rst index b81e35a6..0c0d4556 100644 --- a/docs/abi-spec.rst +++ b/docs/abi-spec.rst @@ -40,21 +40,21 @@ The following elementary types exist: - ``int<M>``: two's complement signed integer type of ``M`` bits, ``0 < M <= 256``, ``M % 8 == 0``. -- ``address``: equivalent to ``uint160``, except for the assumed interpretation and language typing. +- ``address``: equivalent to ``uint160``, except for the assumed interpretation and language typing. For computing the function selector, ``address`` is used. -- ``uint``, ``int``: synonyms for ``uint256``, ``int256`` respectively (this shorthand not to be used for computing the function selector). +- ``uint``, ``int``: synonyms for ``uint256``, ``int256`` respectively. For computing the function selector, ``uint256`` and ``int256`` have to be used. -- ``bool``: equivalent to ``uint8`` restricted to the values 0 and 1 +- ``bool``: equivalent to ``uint8`` restricted to the values 0 and 1. For computing the function selector, ``bool`` is used. - ``fixed<M>x<N>``: signed fixed-point decimal number of ``M`` bits, ``8 <= M <= 256``, ``M % 8 ==0``, and ``0 < N <= 80``, which denotes the value ``v`` as ``v / (10 ** N)``. - ``ufixed<M>x<N>``: unsigned variant of ``fixed<M>x<N>``. -- ``fixed``, ``ufixed``: synonyms for ``fixed128x19``, ``ufixed128x19`` respectively (this shorthand not to be used for computing the function selector). +- ``fixed``, ``ufixed``: synonyms for ``fixed128x19``, ``ufixed128x19`` respectively. For computing the function selector, ``fixed128x19`` and ``ufixed128x19`` have to be used. - ``bytes<M>``: binary type of ``M`` bytes, ``0 < M <= 32``. -- ``function``: equivalent to ``bytes24``: an address, followed by a function selector +- ``function``: an address (20 bytes) folled by a function selector (4 bytes). Encoded identical to ``bytes24``. The following (fixed-size) array type exists: diff --git a/docs/contracts.rst b/docs/contracts.rst index fcc26b24..afc32b16 100644 --- a/docs/contracts.rst +++ b/docs/contracts.rst @@ -939,15 +939,15 @@ derived override, but this function will bypass function kill() public { /* do cleanup 2 */ super.kill(); } } - contract Final is Base2, Base1 { + contract Final is Base1, Base2 { } -If ``Base1`` calls a function of ``super``, it does not simply +If ``Base2`` calls a function of ``super``, it does not simply call this function on one of its base contracts. Rather, it calls this function on the next base contract in the final -inheritance graph, so it will call ``Base2.kill()`` (note that +inheritance graph, so it will call ``Base1.kill()`` (note that the final inheritance sequence is -- starting with the most -derived contract: Final, Base1, Base2, mortal, owned). +derived contract: Final, Base2, Base1, mortal, owned). The actual function that is called when using super is not known in the context of the class where it is used, although its type is known. This is similar for ordinary @@ -1100,7 +1100,11 @@ is executed in the context of the calling contract, i.e. ``this`` points to the calling contract, and especially the storage from the calling contract can be accessed. As a library is an isolated piece of source code, it can only access state variables of the calling contract if they are explicitly supplied (it -would have no way to name them, otherwise). +would have no way to name them, otherwise). Library functions can only be +called directly (i.e. without the use of ``DELEGATECALL``) if they do not modify +the state (i.e. if they are ``view`` or ``pure`` functions), +because libraries are assumed to be stateless. In particular, it is +not possible to destroy a library unless Solidity's type system is circumvented. Libraries can be seen as implicit base contracts of the contracts that use them. They will not be explicitly visible in the inheritance hierarchy, but calls @@ -1111,7 +1115,7 @@ if the library were a base contract. Of course, calls to internal functions use the internal calling convention, which means that all internal types can be passed and memory types will be passed by reference and not copied. To realize this in the EVM, code of internal library functions -and all functions called from therein will be pulled into the calling +and all functions called from therein will at compile time be pulled into the calling contract, and a regular ``JUMP`` call will be used instead of a ``DELEGATECALL``. .. index:: using for, set @@ -1268,6 +1272,30 @@ Restrictions for libraries in comparison to contracts: (These might be lifted at a later point.) +Call Protection For Libraries +============================= + +As mentioned in the introduction, if a library's code is executed +using a ``CALL`` instead of a ``DELEGATECALL`` or ``CALLCODE``, +it will revert unless a ``view`` or ``pure`` function is called. + +The EVM does not provide a direct way for a contract to detect +whether it was called using ``CALL`` or not, but a contract +can use the ``ADDRESS`` opcode to find out "where" it is +currently running. The generated code compares this address +to the address used at construction time to determine the mode +of calling. + +More specifically, the runtime code of a library always starts +with a push instruction, which is a zero of 20 bytes at +compilation time. When the deploy code runs, this constant +is replaced in memory by the current address and this +modified code is stored in the contract. At runtime, +this causes the deploy time address to be the first +constant to be pushed onto the stack and the dispatcher +code compares the current address against this constant +for any non-view and non-pure function. + .. index:: ! using for, library .. _using-for: |