Skip to content

Instantly share code, notes, and snippets.

@chriseth

chriseth/docdiff.patch

Created February 20, 2018 11:43
Show Gist options
  • Save chriseth/5e06fb08433a03d1e4c05224f4287264 to your computer and use it in GitHub Desktop.
Save chriseth/5e06fb08433a03d1e4c05224f4287264 to your computer and use it in GitHub Desktop.
Download ZIP
Differences in Solidity documentation between 26ea9ce07cf85849cd881465a4322f14bff87eb8 and a6b52fdc34650c74597c1bcdc5075b6375c62650
Raw
docdiff.patch
diff --git a/docs/abi-spec.rst b/docs/abi-spec.rst
index e39c8861..8095a3b7 100644
--- a/docs/abi-spec.rst
+++ b/docs/abi-spec.rst
@@ -6,17 +6,19 @@
Application Binary Interface Specification
******************************************
-Basic design
+Basic Design
============
The Application Binary Interface is the standard way to interact with contracts in the Ethereum ecosystem, both
-from outside the blockchain and for contract-to-contract interaction. Data is encoded following its type,
-according to this specification.
+from outside the blockchain and for contract-to-contract interaction. Data is encoded according to its type,
+as described in this specification. The encoding is not self describing and thus requires a schema in order to decode.
-We assume the Application Binary Interface (ABI) is strongly typed, known at compilation time and static. No introspection mechanism will be provided. We assert that all contracts will have the interface definitions of any contracts they call available at compile-time.
+We assume the interface functions of a contract are strongly typed, known at compilation time and static. No introspection mechanism will be provided. We assume that all contracts will have the interface definitions of any contracts they call available at compile-time.
This specification does not address contracts whose interface is dynamic or otherwise known only at run-time. Should these cases become important they can be adequately handled as facilities built within the Ethereum ecosystem.
+.. _abi_function_selector:
+
Function Selector
=================
@@ -34,45 +36,47 @@ Types
The following elementary types exist:
-- `uint<M>`: unsigned integer type of `M` bits, `0 < M <= 256`, `M % 8 == 0`. e.g. `uint32`, `uint8`, `uint256`.
+- ``uint<M>``: unsigned integer type of ``M`` bits, ``0 < M <= 256``, ``M % 8 == 0``. e.g. ``uint32``, ``uint8``, ``uint256``.
-- `int<M>`: two's complement signed integer type of `M` bits, `0 < M <= 256`, `M % 8 == 0`.
+- ``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 (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, `0 < M <= 256`, `M % 8 ==0`, and `0 < N <= 80`, which denotes the value `v` as `v / (10 ** N)`.
+- ``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>`.
+- ``ufixed<M>x<N>``: unsigned variant of ``fixed<M>x<N>``.
-- `fixed`, `ufixed`: synonyms for `fixed128x19`, `ufixed128x19` respectively (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`.
+- ``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:
-- `<type>[M]`: a fixed-length array of the given fixed-length type.
+- ``<type>[M]``: a fixed-length array of ``M`` elements, ``M > 0``, of the given type.
-The following non-fixed-size types exist:
+The following non-fixed-size types exist:
-- `bytes`: dynamic sized byte sequence.
+- ``bytes``: dynamic sized byte sequence.
-- `string`: dynamic sized unicode string assumed to be UTF-8 encoded.
+- ``string``: dynamic sized unicode string assumed to be UTF-8 encoded.
-- `<type>[]`: a variable-length array of the given fixed-length type.
+- ``<type>[]``: a variable-length array of elements of the given type.
-Types can be combined to anonymous structs by enclosing a finite non-negative number
+Types can be combined to a tuple by enclosing a finite non-negative number
of them inside parentheses, separated by commas:
-- `(T1,T2,...,Tn)`: anonymous struct (ordered tuple) consisting of the types `T1`, ..., `Tn`, `n >= 0`
+- ``(T1,T2,...,Tn)``: tuple consisting of the types ``T1``, ..., ``Tn``, ``n >= 0``
-It is possible to form structs of structs, arrays of structs and so on.
+It is possible to form tuples of tuples, arrays of tuples and so on.
+.. note::
+ Solidity supports all the types presented above with the same names with the exception of tuples. The ABI tuple type is utilised for encoding Solidity ``structs``.
Formal Specification of the Encoding
====================================
@@ -82,97 +86,99 @@ properties, which are especially useful if some arguments are nested arrays:
Properties:
- 1. The number of reads necessary to access a value is at most the depth of the value inside the argument array structure, i.e. four reads are needed to retrieve `a_i[k][l][r]`. In a previous version of the ABI, the number of reads scaled linearly with the total number of dynamic parameters in the worst case.
+ 1. The number of reads necessary to access a value is at most the depth of the value inside the argument array structure, i.e. four reads are needed to retrieve ``a_i[k][l][r]``. In a previous version of the ABI, the number of reads scaled linearly with the total number of dynamic parameters in the worst case.
2. The data of a variable or array element is not interleaved with other data and it is relocatable, i.e. it only uses relative "addresses"
We distinguish static and dynamic types. Static types are encoded in-place and dynamic types are encoded at a separately allocated location after the current block.
**Definition:** The following types are called "dynamic":
-* `bytes`
-* `string`
-* `T[]` for any `T`
-* `T[k]` for any dynamic `T` and any `k > 0`
+
+* ``bytes``
+* ``string``
+* ``T[]`` for any ``T``
+* ``T[k]`` for any dynamic ``T`` and any ``k > 0``
+* ``(T1,...,Tk)`` if any ``Ti`` is dynamic for ``1 <= i <= k``
All other types are called "static".
-**Definition:** `len(a)` is the number of bytes in a binary string `a`.
-The type of `len(a)` is assumed to be `uint256`.
+**Definition:** ``len(a)`` is the number of bytes in a binary string ``a``.
+The type of ``len(a)`` is assumed to be ``uint256``.
-We define `enc`, the actual encoding, as a mapping of values of the ABI types to binary strings such
-that `len(enc(X))` depends on the value of `X` if and only if the type of `X` is dynamic.
+We define ``enc``, the actual encoding, as a mapping of values of the ABI types to binary strings such
+that ``len(enc(X))`` depends on the value of ``X`` if and only if the type of ``X`` is dynamic.
-**Definition:** For any ABI value `X`, we recursively define `enc(X)`, depending
-on the type of `X` being
+**Definition:** For any ABI value ``X``, we recursively define ``enc(X)``, depending
+on the type of ``X`` being
-- `(T1,...,Tk)` for `k >= 0` and any types `T1`, ..., `Tk`
+- ``(T1,...,Tk)`` for ``k >= 0`` and any types ``T1``, ..., ``Tk``
- `enc(X) = head(X(1)) ... head(X(k-1)) tail(X(0)) ... tail(X(k-1))`
+ ``enc(X) = head(X(1)) ... head(X(k-1)) tail(X(0)) ... tail(X(k-1))``
- where `X(i)` is the `ith` component of the value, and
- `head` and `tail` are defined for `Ti` being a static type as
+ where ``X(i)`` is the ``ith`` component of the value, and
+ ``head`` and ``tail`` are defined for ``Ti`` being a static type as
- `head(X(i)) = enc(X(i))` and `tail(X(i)) = ""` (the empty string)
+ ``head(X(i)) = enc(X(i))`` and ``tail(X(i)) = ""`` (the empty string)
and as
- `head(X(i)) = enc(len(head(X(0)) ... head(X(k-1)) tail(X(0)) ... tail(X(i-1))))`
- `tail(X(i)) = enc(X(i))`
+ ``head(X(i)) = enc(len(head(X(0)) ... head(X(k-1)) tail(X(0)) ... tail(X(i-1))))``
+ ``tail(X(i)) = enc(X(i))``
- otherwise, i.e. if `Ti` is a dynamic type.
+ otherwise, i.e. if ``Ti`` is a dynamic type.
- Note that in the dynamic case, `head(X(i))` is well-defined since the lengths of
+ Note that in the dynamic case, ``head(X(i))`` is well-defined since the lengths of
the head parts only depend on the types and not the values. Its value is the offset
- of the beginning of `tail(X(i))` relative to the start of `enc(X)`.
-
-- `T[k]` for any `T` and `k`:
+ of the beginning of ``tail(X(i))`` relative to the start of ``enc(X)``.
+
+- ``T[k]`` for any ``T`` and ``k``:
- `enc(X) = enc((X[0], ..., X[k-1]))`
-
- i.e. it is encoded as if it were an anonymous struct with `k` elements
+ ``enc(X) = enc((X[0], ..., X[k-1]))``
+
+ i.e. it is encoded as if it were a tuple with ``k`` elements
of the same type.
-
-- `T[]` where `X` has `k` elements (`k` is assumed to be of type `uint256`):
- `enc(X) = enc(k) enc([X[1], ..., X[k]])`
+- ``T[]`` where ``X`` has ``k`` elements (``k`` is assumed to be of type ``uint256``):
+
+ ``enc(X) = enc(k) enc([X[1], ..., X[k]])``
- i.e. it is encoded as if it were an array of static size `k`, prefixed with
+ i.e. it is encoded as if it were an array of static size ``k``, prefixed with
the number of elements.
-- `bytes`, of length `k` (which is assumed to be of type `uint256`):
+- ``bytes``, of length ``k`` (which is assumed to be of type ``uint256``):
- `enc(X) = enc(k) pad_right(X)`, i.e. the number of bytes is encoded as a
- `uint256` followed by the actual value of `X` as a byte sequence, followed by
- the minimum number of zero-bytes such that `len(enc(X))` is a multiple of 32.
+ ``enc(X) = enc(k) pad_right(X)``, i.e. the number of bytes is encoded as a
+ ``uint256`` followed by the actual value of ``X`` as a byte sequence, followed by
+ the minimum number of zero-bytes such that ``len(enc(X))`` is a multiple of 32.
-- `string`:
+- ``string``:
- `enc(X) = enc(enc_utf8(X))`, i.e. `X` is utf-8 encoded and this value is interpreted as of `bytes` type and encoded further. Note that the length used in this subsequent encoding is the number of bytes of the utf-8 encoded string, not its number of characters.
+ ``enc(X) = enc(enc_utf8(X))``, i.e. ``X`` is utf-8 encoded and this value is interpreted as of ``bytes`` type and encoded further. Note that the length used in this subsequent encoding is the number of bytes of the utf-8 encoded string, not its number of characters.
-- `uint<M>`: `enc(X)` is the big-endian encoding of `X`, padded on the higher-order (left) side with zero-bytes such that the length is a multiple of 32 bytes.
-- `address`: as in the `uint160` case
-- `int<M>`: `enc(X)` is the big-endian two's complement encoding of `X`, padded on the higher-oder (left) side with `0xff` for negative `X` and with zero bytes for positive `X` such that the length is a multiple of 32 bytes.
-- `bool`: as in the `uint8` case, where `1` is used for `true` and `0` for `false`
-- `fixed<M>x<N>`: `enc(X)` is `enc(X * 10**N)` where `X * 10**N` is interpreted as a `int256`.
-- `fixed`: as in the `fixed128x19` case
-- `ufixed<M>x<N>`: `enc(X)` is `enc(X * 10**N)` where `X * 10**N` is interpreted as a `uint256`.
-- `ufixed`: as in the `ufixed128x19` case
-- `bytes<M>`: `enc(X)` is the sequence of bytes in `X` padded with zero-bytes to a length of 32.
+- ``uint<M>``: ``enc(X)`` is the big-endian encoding of ``X``, padded on the higher-order (left) side with zero-bytes such that the length is a multiple of 32 bytes.
+- ``address``: as in the ``uint160`` case
+- ``int<M>``: ``enc(X)`` is the big-endian two's complement encoding of ``X``, padded on the higher-oder (left) side with ``0xff`` for negative ``X`` and with zero bytes for positive ``X`` such that the length is a multiple of 32 bytes.
+- ``bool``: as in the ``uint8`` case, where ``1`` is used for ``true`` and ``0`` for ``false``
+- ``fixed<M>x<N>``: ``enc(X)`` is ``enc(X * 10**N)`` where ``X * 10**N`` is interpreted as a ``int256``.
+- ``fixed``: as in the ``fixed128x19`` case
+- ``ufixed<M>x<N>``: ``enc(X)`` is ``enc(X * 10**N)`` where ``X * 10**N`` is interpreted as a ``uint256``.
+- ``ufixed``: as in the ``ufixed128x19`` case
+- ``bytes<M>``: ``enc(X)`` is the sequence of bytes in ``X`` padded with zero-bytes to a length of 32.
-Note that for any `X`, `len(enc(X))` is a multiple of 32.
+Note that for any ``X``, ``len(enc(X))`` is a multiple of 32.
Function Selector and Argument Encoding
=======================================
-All in all, a call to the function `f` with parameters `a_1, ..., a_n` is encoded as
+All in all, a call to the function ``f`` with parameters ``a_1, ..., a_n`` is encoded as
- `function_selector(f) enc((a_1, ..., a_n))`
+ ``function_selector(f) enc((a_1, ..., a_n))``
-and the return values `v_1, ..., v_k` of `f` are encoded as
+and the return values ``v_1, ..., v_k`` of ``f`` are encoded as
- `enc((v_1, ..., v_k))`
+ ``enc((v_1, ..., v_k))``
-i.e. the values are combined into an anonymous struct and encoded.
+i.e. the values are combined into a tuple and encoded.
Examples
========
@@ -181,46 +187,49 @@ Given the contract:
::
+ pragma solidity ^0.4.16;
+
contract Foo {
- function bar(bytes3[2] xy) {}
- function baz(uint32 x, bool y) returns (bool r) { r = x > 32 || y; }
- function sam(bytes name, bool z, uint[] data) {}
+ function bar(bytes3[2]) public pure {}
+ function baz(uint32 x, bool y) public pure returns (bool r) { r = x > 32 || y; }
+ function sam(bytes, bool, uint[]) public pure {}
}
-Thus for our `Foo` example if we wanted to call `baz` with the parameters `69` and `true`, we would pass 68 bytes total, which can be broken down into:
+Thus for our ``Foo`` example if we wanted to call ``baz`` with the parameters ``69`` and ``true``, we would pass 68 bytes total, which can be broken down into:
-- `0xcdcd77c0`: the Method ID. This is derived as the first 4 bytes of the Keccak hash of the ASCII form of the signature `baz(uint32,bool)`.
-- `0x0000000000000000000000000000000000000000000000000000000000000045`: the first parameter, a uint32 value `69` padded to 32 bytes
-- `0x0000000000000000000000000000000000000000000000000000000000000001`: the second parameter - boolean `true`, padded to 32 bytes
+- ``0xcdcd77c0``: the Method ID. This is derived as the first 4 bytes of the Keccak hash of the ASCII form of the signature ``baz(uint32,bool)``.
+- ``0x0000000000000000000000000000000000000000000000000000000000000045``: the first parameter, a uint32 value ``69`` padded to 32 bytes
+- ``0x0000000000000000000000000000000000000000000000000000000000000001``: the second parameter - boolean ``true``, padded to 32 bytes
In total::
0xcdcd77c000000000000000000000000000000000000000000000000000000000000000450000000000000000000000000000000000000000000000000000000000000001
-It returns a single `bool`. If, for example, it were to return `false`, its output would be the single byte array `0x0000000000000000000000000000000000000000000000000000000000000000`, a single bool.
+It returns a single ``bool``. If, for example, it were to return ``false``, its output would be the single byte array ``0x0000000000000000000000000000000000000000000000000000000000000000``, a single bool.
-If we wanted to call `bar` with the argument `["abc", "def"]`, we would pass 68 bytes total, broken down into:
+If we wanted to call ``bar`` with the argument ``["abc", "def"]``, we would pass 68 bytes total, broken down into:
-- `0xfce353f6`: the Method ID. This is derived from the signature `bar(bytes3[2])`.
-- `0x6162630000000000000000000000000000000000000000000000000000000000`: the first part of the first parameter, a `bytes3` value `"abc"` (left-aligned).
-- `0x6465660000000000000000000000000000000000000000000000000000000000`: the second part of the first parameter, a `bytes3` value `"def"` (left-aligned).
+- ``0xfce353f6``: the Method ID. This is derived from the signature ``bar(bytes3[2])``.
+- ``0x6162630000000000000000000000000000000000000000000000000000000000``: the first part of the first parameter, a ``bytes3`` value ``"abc"`` (left-aligned).
+- ``0x6465660000000000000000000000000000000000000000000000000000000000``: the second part of the first parameter, a ``bytes3`` value ``"def"`` (left-aligned).
In total::
0xfce353f661626300000000000000000000000000000000000000000000000000000000006465660000000000000000000000000000000000000000000000000000000000
-If we wanted to call `sam` with the arguments `"dave"`, `true` and `[1,2,3]`, we would pass 292 bytes total, broken down into:
-- `0xa5643bf2`: the Method ID. This is derived from the signature `sam(bytes,bool,uint256[])`. Note that `uint` is replaced with its canonical representation `uint256`.
-- `0x0000000000000000000000000000000000000000000000000000000000000060`: the location of the data part of the first parameter (dynamic type), measured in bytes from the start of the arguments block. In this case, `0x60`.
-- `0x0000000000000000000000000000000000000000000000000000000000000001`: the second parameter: boolean true.
-- `0x00000000000000000000000000000000000000000000000000000000000000a0`: the location of the data part of the third parameter (dynamic type), measured in bytes. In this case, `0xa0`.
-- `0x0000000000000000000000000000000000000000000000000000000000000004`: the data part of the first argument, it starts with the length of the byte array in elements, in this case, 4.
-- `0x6461766500000000000000000000000000000000000000000000000000000000`: the contents of the first argument: the UTF-8 (equal to ASCII in this case) encoding of `"dave"`, padded on the right to 32 bytes.
-- `0x0000000000000000000000000000000000000000000000000000000000000003`: the data part of the third argument, it starts with the length of the array in elements, in this case, 3.
-- `0x0000000000000000000000000000000000000000000000000000000000000001`: the first entry of the third parameter.
-- `0x0000000000000000000000000000000000000000000000000000000000000002`: the second entry of the third parameter.
-- `0x0000000000000000000000000000000000000000000000000000000000000003`: the third entry of the third parameter.
+If we wanted to call ``sam`` with the arguments ``"dave"``, ``true`` and ``[1,2,3]``, we would pass 292 bytes total, broken down into:
+
+- ``0xa5643bf2``: the Method ID. This is derived from the signature ``sam(bytes,bool,uint256[])``. Note that ``uint`` is replaced with its canonical representation ``uint256``.
+- ``0x0000000000000000000000000000000000000000000000000000000000000060``: the location of the data part of the first parameter (dynamic type), measured in bytes from the start of the arguments block. In this case, ``0x60``.
+- ``0x0000000000000000000000000000000000000000000000000000000000000001``: the second parameter: boolean true.
+- ``0x00000000000000000000000000000000000000000000000000000000000000a0``: the location of the data part of the third parameter (dynamic type), measured in bytes. In this case, ``0xa0``.
+- ``0x0000000000000000000000000000000000000000000000000000000000000004``: the data part of the first argument, it starts with the length of the byte array in elements, in this case, 4.
+- ``0x6461766500000000000000000000000000000000000000000000000000000000``: the contents of the first argument: the UTF-8 (equal to ASCII in this case) encoding of ``"dave"``, padded on the right to 32 bytes.
+- ``0x0000000000000000000000000000000000000000000000000000000000000003``: the data part of the third argument, it starts with the length of the array in elements, in this case, 3.
+- ``0x0000000000000000000000000000000000000000000000000000000000000001``: the first entry of the third parameter.
+- ``0x0000000000000000000000000000000000000000000000000000000000000002``: the second entry of the third parameter.
+- ``0x0000000000000000000000000000000000000000000000000000000000000003``: the third entry of the third parameter.
In total::
@@ -229,26 +238,26 @@ In total::
Use of Dynamic Types
====================
-A call to a function with the signature `f(uint,uint32[],bytes10,bytes)` with values `(0x123, [0x456, 0x789], "1234567890", "Hello, world!")` is encoded in the following way:
+A call to a function with the signature ``f(uint,uint32[],bytes10,bytes)`` with values ``(0x123, [0x456, 0x789], "1234567890", "Hello, world!")`` is encoded in the following way:
-We take the first four bytes of `sha3("f(uint256,uint32[],bytes10,bytes)")`, i.e. `0x8be65246`.
-Then we encode the head parts of all four arguments. For the static types `uint256` and `bytes10`, these are directly the values we want to pass, whereas for the dynamic types `uint32[]` and `bytes`, we use the offset in bytes to the start of their data area, measured from the start of the value encoding (i.e. not counting the first four bytes containing the hash of the function signature). These are:
+We take the first four bytes of ``sha3("f(uint256,uint32[],bytes10,bytes)")``, i.e. ``0x8be65246``.
+Then we encode the head parts of all four arguments. For the static types ``uint256`` and ``bytes10``, these are directly the values we want to pass, whereas for the dynamic types ``uint32[]`` and ``bytes``, we use the offset in bytes to the start of their data area, measured from the start of the value encoding (i.e. not counting the first four bytes containing the hash of the function signature). These are:
- - `0x0000000000000000000000000000000000000000000000000000000000000123` (`0x123` padded to 32 bytes)
- - `0x0000000000000000000000000000000000000000000000000000000000000080` (offset to start of data part of second parameter, 4*32 bytes, exactly the size of the head part)
- - `0x3132333435363738393000000000000000000000000000000000000000000000` (`"1234567890"` padded to 32 bytes on the right)
- - `0x00000000000000000000000000000000000000000000000000000000000000e0` (offset to start of data part of fourth parameter = offset to start of data part of first dynamic parameter + size of data part of first dynamic parameter = 4\*32 + 3\*32 (see below))
+ - ``0x0000000000000000000000000000000000000000000000000000000000000123`` (``0x123`` padded to 32 bytes)
+ - ``0x0000000000000000000000000000000000000000000000000000000000000080`` (offset to start of data part of second parameter, 4*32 bytes, exactly the size of the head part)
+ - ``0x3132333435363738393000000000000000000000000000000000000000000000`` (``"1234567890"`` padded to 32 bytes on the right)
+ - ``0x00000000000000000000000000000000000000000000000000000000000000e0`` (offset to start of data part of fourth parameter = offset to start of data part of first dynamic parameter + size of data part of first dynamic parameter = 4\*32 + 3\*32 (see below))
-After this, the data part of the first dynamic argument, `[0x456, 0x789]` follows:
+After this, the data part of the first dynamic argument, ``[0x456, 0x789]`` follows:
- - `0x0000000000000000000000000000000000000000000000000000000000000002` (number of elements of the array, 2)
- - `0x0000000000000000000000000000000000000000000000000000000000000456` (first element)
- - `0x0000000000000000000000000000000000000000000000000000000000000789` (second element)
+ - ``0x0000000000000000000000000000000000000000000000000000000000000002`` (number of elements of the array, 2)
+ - ``0x0000000000000000000000000000000000000000000000000000000000000456`` (first element)
+ - ``0x0000000000000000000000000000000000000000000000000000000000000789`` (second element)
-Finally, we encode the data part of the second dynamic argument, `"Hello, world!"`:
+Finally, we encode the data part of the second dynamic argument, ``"Hello, world!"``:
- - `0x000000000000000000000000000000000000000000000000000000000000000d` (number of elements (bytes in this case): 13)
- - `0x48656c6c6f2c20776f726c642100000000000000000000000000000000000000` (`"Hello, world!"` padded to 32 bytes on the right)
+ - ``0x000000000000000000000000000000000000000000000000000000000000000d`` (number of elements (bytes in this case): 13)
+ - ``0x48656c6c6f2c20776f726c642100000000000000000000000000000000000000`` (``"Hello, world!"`` padded to 32 bytes on the right)
All together, the encoding is (newline after function selector and each 32-bytes for clarity):
@@ -270,56 +279,68 @@ Events
Events are an abstraction of the Ethereum logging/event-watching protocol. Log entries provide the contract's address, a series of up to four topics and some arbitrary length binary data. Events leverage the existing function ABI in order to interpret this (together with an interface spec) as a properly typed structure.
-Given an event name and series of event parameters, we split them into two sub-series: those which are indexed and those which are not. Those which are indexed, which may number up to 3, are used alongside the Keccak hash of the event signature to form the topics of the log entry. Those which as not indexed form the byte array of the event.
+Given an event name and series of event parameters, we split them into two sub-series: those which are indexed and those which are not. Those which are indexed, which may number up to 3, are used alongside the Keccak hash of the event signature to form the topics of the log entry. Those which are not indexed form the byte array of the event.
In effect, a log entry using this ABI is described as:
-- `address`: the address of the contract (intrinsically provided by Ethereum);
-- `topics[0]`: `keccak(EVENT_NAME+"("+EVENT_ARGS.map(canonical_type_of).join(",")+")")` (`canonical_type_of` is a function that simply returns the canonical type of a given argument, e.g. for `uint indexed foo`, it would return `uint256`). If the event is declared as `anonymous` the `topics[0]` is not generated;
-- `topics[n]`: `EVENT_INDEXED_ARGS[n - 1]` (`EVENT_INDEXED_ARGS` is the series of `EVENT_ARGS` that are indexed);
-- `data`: `abi_serialise(EVENT_NON_INDEXED_ARGS)` (`EVENT_NON_INDEXED_ARGS` is the series of `EVENT_ARGS` that are not indexed, `abi_serialise` is the ABI serialisation function used for returning a series of typed values from a function, as described above).
+- ``address``: the address of the contract (intrinsically provided by Ethereum);
+- ``topics[0]``: ``keccak(EVENT_NAME+"("+EVENT_ARGS.map(canonical_type_of).join(",")+")")`` (``canonical_type_of`` is a function that simply returns the canonical type of a given argument, e.g. for ``uint indexed foo``, it would return ``uint256``). If the event is declared as ``anonymous`` the ``topics[0]`` is not generated;
+- ``topics[n]``: ``EVENT_INDEXED_ARGS[n - 1]`` (``EVENT_INDEXED_ARGS`` is the series of ``EVENT_ARGS`` that are indexed);
+- ``data``: ``abi_serialise(EVENT_NON_INDEXED_ARGS)`` (``EVENT_NON_INDEXED_ARGS`` is the series of ``EVENT_ARGS`` that are not indexed, ``abi_serialise`` is the ABI serialisation function used for returning a series of typed values from a function, as described above).
+
+For all fixed-length Solidity types, the ``EVENT_INDEXED_ARGS`` array contains the 32-byte encoded value directly. However, for *types of dynamic length*, which include ``string``, ``bytes``, and arrays, ``EVENT_INDEXED_ARGS`` will contain the *Keccak hash* of the encoded value, rather than the encoded value directly. This allows applications to efficiently query for values of dynamic-length types (by setting the hash of the encoded value as the topic), but leaves applications unable to decode indexed values they have not queried for. For dynamic-length types, application developers face a trade-off between fast search for predetermined values (if the argument is indexed) and legibility of arbitrary values (which requires that the arguments not be indexed). Developers may overcome this tradeoff and achieve both efficient search and arbitrary legibility by defining events with two arguments — one indexed, one not — intended to hold the same value.
JSON
====
-The JSON format for a contract's interface is given by an array of function and/or event descriptions. A function description is a JSON object with the fields:
+The JSON format for a contract's interface is given by an array of function and/or event descriptions.
+A function description is a JSON object with the fields:
+
+- ``type``: ``"function"``, ``"constructor"``, or ``"fallback"`` (the :ref:`unnamed "default" function <fallback-function>`);
+- ``name``: the name of the function;
+- ``inputs``: an array of objects, each of which contains:
+
+ * ``name``: the name of the parameter;
+ * ``type``: the canonical type of the parameter (more below).
+ * ``components``: used for tuple types (more below).
-- `type`: `"function"`, `"constructor"`, or `"fallback"` (the :ref:`unnamed "default" function <fallback-function>`);
-- `name`: the name of the function;
-- `inputs`: an array of objects, each of which contains:
- * `name`: the name of the parameter;
- * `type`: the canonical type of the parameter.
-- `outputs`: an array of objects similar to `inputs`, can be omitted if function doesn't return anything;
-- `constant`: `true` if function is :ref:`specified to not modify blockchain state <constant-functions>`);
-- `payable`: `true` if function accepts ether, defaults to `false`.
+- ``outputs``: an array of objects similar to ``inputs``, can be omitted if function doesn't return anything;
+- ``payable``: ``true`` if function accepts ether, defaults to ``false``;
+- ``stateMutability``: a string with one of the following values: ``pure`` (:ref:`specified to not read blockchain state <pure-functions>`), ``view`` (:ref:`specified to not modify the blockchain state <view-functions>`), ``nonpayable`` and ``payable`` (same as ``payable`` above).
+- ``constant``: ``true`` if function is either ``pure`` or ``view``
-`type` can be omitted, defaulting to `"function"`.
+``type`` can be omitted, defaulting to ``"function"``.
-Constructor and fallback function never have `name` or `outputs`. Fallback function doesn't have `inputs` either.
+Constructor and fallback function never have ``name`` or ``outputs``. Fallback function doesn't have ``inputs`` either.
Sending non-zero ether to non-payable function will throw. Don't do it.
An event description is a JSON object with fairly similar fields:
-- `type`: always `"event"`
-- `name`: the name of the event;
-- `inputs`: an array of objects, each of which contains:
- * `name`: the name of the parameter;
- * `type`: the canonical type of the parameter.
- * `indexed`: `true` if the field is part of the log's topics, `false` if it one of the log's data segment.
-- `anonymous`: `true` if the event was declared as `anonymous`.
+- ``type``: always ``"event"``
+- ``name``: the name of the event;
+- ``inputs``: an array of objects, each of which contains:
-For example,
+ * ``name``: the name of the parameter;
+ * ``type``: the canonical type of the parameter (more below).
+ * ``components``: used for tuple types (more below).
+ * ``indexed``: ``true`` if the field is part of the log's topics, ``false`` if it one of the log's data segment.
+
+- ``anonymous``: ``true`` if the event was declared as ``anonymous``.
+
+For example,
::
- contract Test {
- function Test(){ b = 0x12345678901234567890123456789012; }
- event Event(uint indexed a, bytes32 b)
- event Event2(uint indexed a, bytes32 b)
- function foo(uint a) { Event(a, b); }
- bytes32 b;
- }
+ pragma solidity ^0.4.0;
+
+ contract Test {
+ function Test() public { b = 0x12345678901234567890123456789012; }
+ event Event(uint indexed a, bytes32 b);
+ event Event2(uint indexed a, bytes32 b);
+ function foo(uint a) public { Event(a, b); }
+ bytes32 b;
+ }
would result in the JSON:
@@ -334,12 +355,120 @@ would result in the JSON:
"inputs": [{"name":"a","type":"uint256","indexed":true},{"name":"b","type":"bytes32","indexed":false}],
"name":"Event2"
}, {
- "type":"event",
- "inputs": [{"name":"a","type":"uint256","indexed":true},{"name":"b","type":"bytes32","indexed":false}],
- "name":"Event2"
- }, {
"type":"function",
"inputs": [{"name":"a","type":"uint256"}],
"name":"foo",
"outputs": []
}]
+
+Handling tuple types
+--------------------
+
+Despite that names are intentionally not part of the ABI encoding they do make a lot of sense to be included
+in the JSON to enable displaying it to the end user. The structure is nested in the following way:
+
+An object with members ``name``, ``type`` and potentially ``components`` describes a typed variable.
+The canonical type is determined until a tuple type is reached and the string description up
+to that point is stored in ``type`` prefix with the word ``tuple``, i.e. it will be ``tuple`` followed by
+a sequence of ``[]`` and ``[k]`` with
+integers ``k``. The components of the tuple are then stored in the member ``components``,
+which is of array type and has the same structure as the top-level object except that
+``indexed`` is not allowed there.
+
+As an example, the code
+
+::
+
+ pragma solidity ^0.4.19;
+ pragma experimental ABIEncoderV2;
+
+ contract Test {
+ struct S { uint a; uint[] b; T[] c; }
+ struct T { uint x; uint y; }
+ function f(S s, T t, uint a) public { }
+ function g() public returns (S s, T t, uint a) {}
+ }
+
+would result in the JSON:
+
+.. code:: json
+
+ [
+ {
+ "name": "f",
+ "type": "function",
+ "inputs": [
+ {
+ "name": "s",
+ "type": "tuple",
+ "components": [
+ {
+ "name": "a",
+ "type": "uint256"
+ },
+ {
+ "name": "b",
+ "type": "uint256[]"
+ },
+ {
+ "name": "c",
+ "type": "tuple[]",
+ "components": [
+ {
+ "name": "x",
+ "type": "uint256"
+ },
+ {
+ "name": "y",
+ "type": "uint256"
+ }
+ ]
+ }
+ ]
+ },
+ {
+ "name": "t",
+ "type": "tuple",
+ "components": [
+ {
+ "name": "x",
+ "type": "uint256"
+ },
+ {
+ "name": "y",
+ "type": "uint256"
+ }
+ ]
+ },
+ {
+ "name": "a",
+ "type": "uint256"
+ }
+ ],
+ "outputs": []
+ }
+ ]
+
+.. _abi_packed_mode:
+
+Non-standard Packed Mode
+========================
+
+Solidity supports a non-standard packed mode where:
+
+- no :ref:`function selector <abi_function_selector>` is encoded,
+- types shorter than 32 bytes are neither zero padded nor sign extended and
+- dynamic types are encoded in-place and without the length.
+
+As an example encoding ``int1, bytes1, uint16, string`` with values ``-1, 0x42, 0x2424, "Hello, world!"`` results in ::
+
+ 0xff42242448656c6c6f2c20776f726c6421
+ ^^ int1(-1)
+ ^^ bytes1(0x42)
+ ^^^^ uint16(0x2424)
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^ string("Hello, world!") without a length field
+
+More specifically, each statically-sized type takes as many bytes as its range has
+and dynamically-sized types like ``string``, ``bytes`` or ``uint[]`` are encoded without
+their length field. This means that the encoding is ambiguous as soon as there are two
+dynamically-sized elements.
diff --git a/docs/assembly.rst b/docs/assembly.rst
index 7ef41483..02522469 100644
--- a/docs/assembly.rst
+++ b/docs/assembly.rst
@@ -9,9 +9,7 @@ This assembly language can also be used as "inline assembly" inside Solidity
source code. We start with describing how to use inline assembly and how it
differs from standalone assembly and then specify assembly itself.
-TODO: Write about how scoping rules of inline assembly are a bit different
-and the complications that arise when for example using internal functions
-of libraries. Furthermore, write about the symbols defined by the compiler.
+.. _inline-assembly:
Inline Assembly
===============
@@ -25,9 +23,10 @@ arising when writing manual assembly by the following features:
* functional-style opcodes: ``mul(1, add(2, 3))`` instead of ``push1 3 push1 2 add push1 1 mul``
* assembly-local variables: ``let x := add(2, 3) let y := mload(0x40) x := add(x, y)``
-* access to external variables: ``function f(uint x) { assembly { x := sub(x, 1) } }``
+* access to external variables: ``function f(uint x) public { assembly { x := sub(x, 1) } }``
* labels: ``let x := 10 repeat: x := sub(x, 1) jumpi(repeat, eq(x, 0))``
* loops: ``for { let i := 0 } lt(i, x) { i := add(i, 1) } { y := mul(2, y) }``
+* if statements: ``if slt(x, 0) { x := sub(0, x) }``
* switch statements: ``switch x case 0 { y := mul(x, 2) } default { y := 0 }``
* function calls: ``function f(x) -> y { switch x case 0 { y := 1 } default { y := mul(x, f(sub(x, 1))) } }``
@@ -38,6 +37,11 @@ We now want to describe the inline assembly language in detail.
at a low level. This discards several important safety
features of Solidity.
+.. note::
+ TODO: Write about how scoping rules of inline assembly are a bit different
+ and the complications that arise when for example using internal functions
+ of libraries. Furthermore, write about the symbols defined by the compiler.
+
Example
-------
@@ -50,7 +54,7 @@ idea is that assembly libraries will be used to enhance the language in such way
pragma solidity ^0.4.0;
library GetCode {
- function at(address _addr) returns (bytes o_code) {
+ function at(address _addr) public view returns (bytes o_code) {
assembly {
// retrieve the size of the code, this needs assembly
let size := extcodesize(_addr)
@@ -74,12 +78,12 @@ you really know what you are doing.
.. code::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
library VectorSum {
// This function is less efficient because the optimizer currently fails to
// remove the bounds checks in array access.
- function sumSolidity(uint[] _data) returns (uint o_sum) {
+ function sumSolidity(uint[] _data) public view returns (uint o_sum) {
for (uint i = 0; i < _data.length; ++i)
o_sum += _data[i];
}
@@ -87,13 +91,38 @@ you really know what you are doing.
// We know that we only access the array in bounds, so we can avoid the check.
// 0x20 needs to be added to an array because the first slot contains the
// array length.
- function sumAsm(uint[] _data) returns (uint o_sum) {
+ function sumAsm(uint[] _data) public view returns (uint o_sum) {
for (uint i = 0; i < _data.length; ++i) {
assembly {
- o_sum := mload(add(add(_data, 0x20), mul(i, 0x20)))
+ o_sum := add(o_sum, mload(add(add(_data, 0x20), mul(i, 0x20))))
}
}
}
+
+ // Same as above, but accomplish the entire code within inline assembly.
+ function sumPureAsm(uint[] _data) public view returns (uint o_sum) {
+ assembly {
+ // Load the length (first 32 bytes)
+ let len := mload(_data)
+
+ // Skip over the length field.
+ //
+ // Keep temporary variable so it can be incremented in place.
+ //
+ // NOTE: incrementing _data would result in an unusable
+ // _data variable after this assembly block
+ let data := add(_data, 0x20)
+
+ // Iterate until the bound is not met.
+ for
+ { let end := add(data, len) }
+ lt(data, end)
+ { data := add(data, 0x20) }
+ {
+ o_sum := add(o_sum, mload(data))
+ }
+ }
+ }
}
@@ -108,7 +137,7 @@ these curly braces, the following can be used (see the later sections for more d
- opcodes (in "instruction style"), e.g. ``mload sload dup1 sstore``, for a list see below
- opcodes in functional style, e.g. ``add(1, mlod(0))``
- labels, e.g. ``name:``
- - variable declarations, e.g. ``let x := 7`` or ``let x := add(y, 3)``
+ - variable declarations, e.g. ``let x := 7``, ``let x := add(y, 3)`` or ``let x`` (initial value of empty (0) is assigned)
- identifiers (labels or assembly-local variables and externals if used as inline assembly), e.g. ``jump(name)``, ``3 x add``
- assignments (in "instruction style"), e.g. ``3 =: x``
- assignments in functional style, e.g. ``x := add(y, 3)``
@@ -123,7 +152,7 @@ following list can be used as a reference of its opcodes.
If an opcode takes arguments (always from the top of the stack), they are given in parentheses.
Note that the order of arguments can be seen to be reversed in non-functional style (explained below).
Opcodes marked with ``-`` do not push an item onto the stack, those marked with ``*`` are
-special and all others push exactly one item onte the stack.
+special and all others push exactly one item onto the stack.
In the following, ``mem[a...b)`` signifies the bytes of memory starting at position ``a`` up to
(excluding) position ``b`` and ``storage[p]`` signifies the storage contents at position ``p``.
@@ -359,7 +388,7 @@ changes during the call, and thus references to local variables will be wrong.
contract C {
uint b;
- function f(uint x) returns (uint r) {
+ function f(uint x) public returns (uint r) {
assembly {
r := mul(x, sload(b_slot)) // ignore the offset, we know it is zero
}
@@ -372,7 +401,7 @@ Labels
Another problem in EVM assembly is that ``jump`` and ``jumpi`` use absolute addresses
which can change easily. Solidity inline assembly provides labels to make the use of
jumps easier. Note that labels are a low-level feature and it is possible to write
-efficient assembly without labels, just using assembly functions, loops and switch instructions
+efficient assembly without labels, just using assembly functions, loops, if and switch instructions
(see below). The following code computes an element in the Fibonacci series.
.. code::
@@ -418,31 +447,6 @@ will have a wrong impression about the stack height at label ``two``:
three:
}
-This problem can be fixed by manually adjusting the stack height for the
-assembler - you can provide a stack height delta that is added
-to the stack height just prior to the label.
-Note that you will not have to care about these things if you just use
-loops and assembly-level functions.
-
-As an example how this can be done in extreme cases, please see the following.
-
-.. code::
-
- {
- let x := 8
- jump(two)
- 0 // This code is unreachable but will adjust the stack height correctly
- one:
- x := 9 // Now x can be accessed properly.
- jump(three)
- pop // Similar negative correction.
- two:
- 7 // push something onto the stack
- jump(one)
- three:
- pop // We have to pop the manually pushed value here again.
- }
-
Declaring Assembly-Local Variables
----------------------------------
@@ -455,10 +459,10 @@ be just ``0``, but it can also be a complex functional-style expression.
.. code::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
contract C {
- function f(uint x) returns (uint b) {
+ function f(uint x) public view returns (uint b) {
assembly {
let v := add(x, 1)
mstore(0x80, v)
@@ -488,13 +492,28 @@ is performed by replacing the variable's value on the stack by the new value.
.. code::
- assembly {
+ {
let v := 0 // functional-style assignment as part of variable declaration
let g := add(v, 2)
sload(10)
=: v // instruction style assignment, puts the result of sload(10) into v
}
+If
+--
+
+The if statement can be used for conditionally executing code.
+There is no "else" part, consider using "switch" (see below) if
+you need multiple alternatives.
+
+.. code::
+
+ {
+ if eq(value, 0) { revert(0, 0) }
+ }
+
+The curly braces for the body are required.
+
Switch
------
@@ -507,7 +526,7 @@ case called ``default``.
.. code::
- assembly {
+ {
let x := 0
switch calldataload(4)
case 0 {
@@ -536,13 +555,27 @@ The following example computes the sum of an area in memory.
.. code::
- assembly {
+ {
let x := 0
for { let i := 0 } lt(i, 0x100) { i := add(i, 0x20) } {
x := add(x, mload(i))
}
}
+For loops can also be written so that they behave like while loops:
+Simply leave the initialization and post-iteration parts empty.
+
+.. code::
+
+ {
+ let x := 0
+ let i := 0
+ for { } lt(i, 0x100) { } { // while(i < 0x100)
+ x := add(x, mload(i))
+ i := add(i, 0x20)
+ }
+ }
+
Functions
---------
@@ -563,7 +596,7 @@ The following example implements the power function by square-and-multiply.
.. code::
- assembly {
+ {
function power(base, exponent) -> result {
switch exponent
case 0 { result := 1 }
@@ -580,7 +613,7 @@ Things to Avoid
---------------
Inline assembly might have a quite high-level look, but it actually is extremely
-low-level. Function calls, loops and switches are converted by simple
+low-level. Function calls, loops, ifs and switches are converted by simple
rewriting rules and after that, the only thing the assembler does for you is re-arranging
functional-style opcodes, managing jump labels, counting stack height for
variable access and removing stack slots for assembly-local variables when the end
@@ -627,7 +660,7 @@ for the Solidity compiler. In this form, it tries to achieve several goals:
3. Control flow should be easy to detect to help in formal verification and optimization.
In order to achieve the first and last goal, assembly provides high-level constructs
-like ``for`` loops, ``switch`` statements and function calls. It should be possible
+like ``for`` loops, ``if`` and ``switch`` statements and function calls. It should be possible
to write assembly programs that do not make use of explicit ``SWAP``, ``DUP``,
``JUMP`` and ``JUMPI`` statements, because the first two obfuscate the data flow
and the last two obfuscate control flow. Furthermore, functional statements of
@@ -677,8 +710,10 @@ Example:
We will follow an example compilation from Solidity to desugared assembly.
We consider the runtime bytecode of the following Solidity program::
+ pragma solidity ^0.4.16;
+
contract C {
- function f(uint x) returns (uint y) {
+ function f(uint x) public pure returns (uint y) {
y = 1;
for (uint i = 0; i < x; i++)
y = 2 * y;
@@ -826,36 +861,37 @@ Grammar::
AssemblyItem =
Identifier |
AssemblyBlock |
- FunctionalAssemblyExpression |
+ AssemblyExpression |
AssemblyLocalDefinition |
- FunctionalAssemblyAssignment |
AssemblyAssignment |
+ AssemblyStackAssignment |
LabelDefinition |
+ AssemblyIf |
AssemblySwitch |
AssemblyFunctionDefinition |
AssemblyFor |
- 'break' | 'continue' |
- SubAssembly | 'dataSize' '(' Identifier ')' |
- LinkerSymbol |
- 'errorLabel' | 'bytecodeSize' |
- NumberLiteral | StringLiteral | HexLiteral
+ 'break' |
+ 'continue' |
+ SubAssembly
+ AssemblyExpression = AssemblyCall | Identifier | AssemblyLiteral
+ AssemblyLiteral = NumberLiteral | StringLiteral | HexLiteral
Identifier = [a-zA-Z_$] [a-zA-Z_0-9]*
- FunctionalAssemblyExpression = Identifier '(' ( AssemblyItem ( ',' AssemblyItem )* )? ')'
- AssemblyLocalDefinition = 'let' IdentifierOrList ':=' FunctionalAssemblyExpression
- FunctionalAssemblyAssignment = IdentifierOrList ':=' FunctionalAssemblyExpression
+ AssemblyCall = Identifier '(' ( AssemblyExpression ( ',' AssemblyExpression )* )? ')'
+ AssemblyLocalDefinition = 'let' IdentifierOrList ( ':=' AssemblyExpression )?
+ AssemblyAssignment = IdentifierOrList ':=' AssemblyExpression
IdentifierOrList = Identifier | '(' IdentifierList ')'
IdentifierList = Identifier ( ',' Identifier)*
- AssemblyAssignment = '=:' Identifier
+ AssemblyStackAssignment = '=:' Identifier
LabelDefinition = Identifier ':'
- AssemblySwitch = 'switch' FunctionalAssemblyExpression AssemblyCase*
+ AssemblyIf = 'if' AssemblyExpression AssemblyBlock
+ AssemblySwitch = 'switch' AssemblyExpression AssemblyCase*
( 'default' AssemblyBlock )?
- AssemblyCase = 'case' FunctionalAssemblyExpression AssemblyBlock
+ AssemblyCase = 'case' AssemblyExpression AssemblyBlock
AssemblyFunctionDefinition = 'function' Identifier '(' IdentifierList? ')'
( '->' '(' IdentifierList ')' )? AssemblyBlock
- AssemblyFor = 'for' ( AssemblyBlock | FunctionalAssemblyExpression)
- FunctionalAssemblyExpression ( AssemblyBlock | FunctionalAssemblyExpression) AssemblyBlock
+ AssemblyFor = 'for' ( AssemblyBlock | AssemblyExpression )
+ AssemblyExpression ( AssemblyBlock | AssemblyExpression ) AssemblyBlock
SubAssembly = 'assembly' Identifier AssemblyBlock
- LinkerSymbol = 'linkerSymbol' '(' StringLiteral ')'
NumberLiteral = HexNumber | DecimalNumber
HexLiteral = 'hex' ('"' ([0-9a-fA-F]{2})* '"' | '\'' ([0-9a-fA-F]{2})* '\'')
StringLiteral = '"' ([^"\r\n\\] | '\\' .)* '"'
@@ -962,8 +998,8 @@ that modifies the stack and with every label that is annotated with a stack
adjustment. Every time a new
local variable is introduced, it is registered together with the current
stack height. If a variable is accessed (either for copying its value or for
-assignment), the appropriate DUP or SWAP instruction is selected depending
-on the difference bitween the current stack height and the
+assignment), the appropriate ``DUP`` or ``SWAP`` instruction is selected depending
+on the difference between the current stack height and the
stack height at the point the variable was introduced.
Pseudocode::
diff --git a/docs/bugs.json b/docs/bugs.json
index 1a67d626..c642793a 100644
--- a/docs/bugs.json
+++ b/docs/bugs.json
@@ -1,5 +1,34 @@
[
{
+ "name": "ZeroFunctionSelector",
+ "summary": "It is possible to craft the name of a function such that it is executed instead of the fallback function in very specific circumstances.",
+ "description": "If a function has a selector consisting only of zeros, is payable and part of a contract that does not have a fallback function and at most five external functions in total, this function is called instead of the fallback function if Ether is sent to the contract without data.",
+ "fixed": "0.4.18",
+ "severity": "very low"
+ },
+ {
+ "name": "DelegateCallReturnValue",
+ "summary": "The low-level .delegatecall() does not return the execution outcome, but converts the value returned by the functioned called to a boolean instead.",
+ "description": "The return value of the low-level .delegatecall() function is taken from a position in memory, where the call data or the return data resides. This value is interpreted as a boolean and put onto the stack. This means if the called function returns at least 32 zero bytes, .delegatecall() returns false even if the call was successuful.",
+ "introduced": "0.3.0",
+ "fixed": "0.4.15",
+ "severity": "low"
+ },
+ {
+ "name": "ECRecoverMalformedInput",
+ "summary": "The ecrecover() builtin can return garbage for malformed input.",
+ "description": "The ecrecover precompile does not properly signal failure for malformed input (especially in the 'v' argument) and thus the Solidity function can return data that was previously present in the return area in memory.",
+ "fixed": "0.4.14",
+ "severity": "medium"
+ },
+ {
+ "name": "SkipEmptyStringLiteral",
+ "summary": "If \"\" is used in a function call, the following function arguments will not be correctly passed to the function.",
+ "description": "If the empty string literal \"\" is used as an argument in a function call, it is skipped by the encoder. This has the effect that the encoding of all arguments following this is shifted left by 32 bytes and thus the function call data is corrupted.",
+ "fixed": "0.4.12",
+ "severity": "low"
+ },
+ {
"name": "ConstantOptimizerSubtraction",
"summary": "In some situations, the optimizer replaces certain numbers in the code with routines that compute different numbers.",
"description": "The optimizer tries to represent any number in the bytecode by routines that compute them with less gas. For some special numbers, an incorrect routine is generated. This could allow an attacker to e.g. trick victims about a specific amount of ether, or function calls to call different functions (or none at all).",
@@ -100,4 +129,4 @@
"severity": "high",
"fixed": "0.3.0"
}
-]
\ No newline at end of file
+]
diff --git a/docs/bugs.rst b/docs/bugs.rst
index 55771a35..7629830d 100644
--- a/docs/bugs.rst
+++ b/docs/bugs.rst
@@ -48,7 +48,7 @@ fixed
publish
The date at which the bug became known publicly, optional
severity
- Severity of the bug: low, medium, high. Takes into account
+ Severity of the bug: very low, low, medium, high. Takes into account
discoverability in contract tests, likelihood of occurrence and
potential damage by exploits.
conditions
diff --git a/docs/bugs_by_version.json b/docs/bugs_by_version.json
index 0f7346b4..5a4c9e29 100644
--- a/docs/bugs_by_version.json
+++ b/docs/bugs_by_version.json
@@ -1,6 +1,9 @@
{
"0.1.0": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"OptimizerStaleKnowledgeAboutSHA3",
@@ -15,6 +18,9 @@
},
"0.1.1": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"OptimizerStaleKnowledgeAboutSHA3",
@@ -29,6 +35,9 @@
},
"0.1.2": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"OptimizerStaleKnowledgeAboutSHA3",
@@ -43,6 +52,9 @@
},
"0.1.3": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"OptimizerStaleKnowledgeAboutSHA3",
@@ -57,6 +69,9 @@
},
"0.1.4": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"OptimizerStaleKnowledgeAboutSHA3",
@@ -71,6 +86,9 @@
},
"0.1.5": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"OptimizerStaleKnowledgeAboutSHA3",
@@ -85,6 +103,9 @@
},
"0.1.6": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -100,6 +121,9 @@
},
"0.1.7": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -115,6 +139,9 @@
},
"0.2.0": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -130,6 +157,9 @@
},
"0.2.1": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -145,6 +175,9 @@
},
"0.2.2": {
"bugs": [
+ "ZeroFunctionSelector",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -160,6 +193,10 @@
},
"0.3.0": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -174,6 +211,10 @@
},
"0.3.1": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -187,6 +228,10 @@
},
"0.3.2": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -200,6 +245,10 @@
},
"0.3.3": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -212,6 +261,10 @@
},
"0.3.4": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -224,6 +277,10 @@
},
"0.3.5": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -236,6 +293,10 @@
},
"0.3.6": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -246,6 +307,10 @@
},
"0.4.0": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -256,6 +321,10 @@
},
"0.4.1": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -266,16 +335,78 @@
},
"0.4.10": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction"
],
"released": "2017-03-15"
},
"0.4.11": {
- "bugs": [],
+ "bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral"
+ ],
"released": "2017-05-03"
},
+ "0.4.12": {
+ "bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput"
+ ],
+ "released": "2017-07-03"
+ },
+ "0.4.13": {
+ "bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput"
+ ],
+ "released": "2017-07-06"
+ },
+ "0.4.14": {
+ "bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue"
+ ],
+ "released": "2017-07-31"
+ },
+ "0.4.15": {
+ "bugs": [
+ "ZeroFunctionSelector"
+ ],
+ "released": "2017-08-08"
+ },
+ "0.4.16": {
+ "bugs": [
+ "ZeroFunctionSelector"
+ ],
+ "released": "2017-08-24"
+ },
+ "0.4.17": {
+ "bugs": [
+ "ZeroFunctionSelector"
+ ],
+ "released": "2017-09-21"
+ },
+ "0.4.18": {
+ "bugs": [],
+ "released": "2017-10-18"
+ },
+ "0.4.19": {
+ "bugs": [],
+ "released": "2017-11-30"
+ },
"0.4.2": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage",
@@ -283,8 +414,16 @@
],
"released": "2016-09-17"
},
+ "0.4.20": {
+ "bugs": [],
+ "released": "2018-02-14"
+ },
"0.4.3": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"HighOrderByteCleanStorage"
@@ -293,6 +432,10 @@
},
"0.4.4": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored"
],
@@ -300,6 +443,10 @@
},
"0.4.5": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored",
"OptimizerStateKnowledgeNotResetForJumpdest"
@@ -308,6 +455,10 @@
},
"0.4.6": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction",
"IdentityPrecompileReturnIgnored"
],
@@ -315,18 +466,30 @@
},
"0.4.7": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction"
],
"released": "2016-12-15"
},
"0.4.8": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction"
],
"released": "2017-01-13"
},
"0.4.9": {
"bugs": [
+ "ZeroFunctionSelector",
+ "DelegateCallReturnValue",
+ "ECRecoverMalformedInput",
+ "SkipEmptyStringLiteral",
"ConstantOptimizerSubtraction"
],
"released": "2017-01-31"
diff --git a/docs/common-patterns.rst b/docs/common-patterns.rst
index acef13b7..7e09f534 100644
--- a/docs/common-patterns.rst
+++ b/docs/common-patterns.rst
@@ -36,12 +36,12 @@ become the new richest.
mapping (address => uint) pendingWithdrawals;
- function WithdrawalContract() payable {
+ function WithdrawalContract() public payable {
richest = msg.sender;
mostSent = msg.value;
}
- function becomeRichest() payable returns (bool) {
+ function becomeRichest() public payable returns (bool) {
if (msg.value > mostSent) {
pendingWithdrawals[richest] += msg.value;
richest = msg.sender;
@@ -52,7 +52,7 @@ become the new richest.
}
}
- function withdraw() {
+ function withdraw() public {
uint amount = pendingWithdrawals[msg.sender];
// Remember to zero the pending refund before
// sending to prevent re-entrancy attacks
@@ -71,12 +71,12 @@ This is as opposed to the more intuitive sending pattern:
address public richest;
uint public mostSent;
- function SendContract() payable {
+ function SendContract() public payable {
richest = msg.sender;
mostSent = msg.value;
}
- function becomeRichest() payable returns (bool) {
+ function becomeRichest() public payable returns (bool) {
if (msg.value > mostSent) {
// This line can cause problems (explained below).
richest.transfer(msg.value);
@@ -93,7 +93,7 @@ Notice that, in this example, an attacker could trap the
contract into an unusable state by causing ``richest`` to be
the address of a contract that has a fallback function
which fails (e.g. by using ``revert()`` or by just
-conssuming more than the 2300 gas stipend). That way,
+consuming more than the 2300 gas stipend). That way,
whenever ``transfer`` is called to deliver funds to the
"poisoned" contract, it will fail and thus also ``becomeRichest``
will fail, with the contract being stuck forever.
@@ -121,7 +121,7 @@ unless you declare make your state variables ``public``.
Furthermore, you can restrict who can make modifications
to your contract's state or call your contract's
-functions and this is what this page is about.
+functions and this is what this section is about.
.. index:: function;modifier
@@ -157,6 +157,7 @@ restrictions highly readable.
/// Make `_newOwner` the new owner of this
/// contract.
function changeOwner(address _newOwner)
+ public
onlyBy(owner)
{
owner = _newOwner;
@@ -171,6 +172,7 @@ restrictions highly readable.
/// May only be called 6 weeks after
/// the contract has been created.
function disown()
+ public
onlyBy(owner)
onlyAfter(creationTime + 6 weeks)
{
@@ -191,6 +193,7 @@ restrictions highly readable.
}
function forceOwnerChange(address _newOwner)
+ public
costs(200 ether)
{
owner = _newOwner;
@@ -310,6 +313,7 @@ function finishes.
// Order of the modifiers matters here!
function bid()
+ public
payable
timedTransitions
atStage(Stages.AcceptingBlindedBids)
@@ -318,6 +322,7 @@ function finishes.
}
function reveal()
+ public
timedTransitions
atStage(Stages.RevealBids)
{
@@ -332,6 +337,7 @@ function finishes.
}
function g()
+ public
timedTransitions
atStage(Stages.AnotherStage)
transitionNext
@@ -339,6 +345,7 @@ function finishes.
}
function h()
+ public
timedTransitions
atStage(Stages.AreWeDoneYet)
transitionNext
@@ -346,6 +353,7 @@ function finishes.
}
function i()
+ public
timedTransitions
atStage(Stages.Finished)
{
diff --git a/docs/contracts.rst b/docs/contracts.rst
index 356fa90d..afc32b16 100644
--- a/docs/contracts.rst
+++ b/docs/contracts.rst
@@ -10,57 +10,29 @@ variables. Calling a function on a different contract (instance) will perform
an EVM function call and thus switch the context such that state variables are
inaccessible.
-.. index:: ! contract;creation
+.. index:: ! contract;creation, constructor
******************
Creating Contracts
******************
-Contracts can be created "from outside" or from Solidity contracts.
+Contracts can be created "from outside" via Ethereum transactions or from within Solidity contracts.
+
+IDEs, such as `Remix <https://remix.ethereum.org/>`_, make the creation process seamless using UI elements.
+
+Creating contracts programatically on Ethereum is best done via using the JavaScript API `web3.js <https://github.com/ethereum/web3.js>`_.
+As of today it has a method called `web3.eth.Contract <https://web3js.readthedocs.io/en/1.0/web3-eth-contract.html#new-contract>`_
+to facilitate contract creation.
+
When a contract is created, its constructor (a function with the same
name as the contract) is executed once.
-
A constructor is optional. Only one constructor is allowed, and this means
overloading is not supported.
-From ``web3.js``, i.e. the JavaScript
-API, this is done as follows::
-
- // Need to specify some source including contract name for the data param below
- var source = "contract CONTRACT_NAME { function CONTRACT_NAME(uint a, uint b) {} }";
-
- // The json abi array generated by the compiler
- var abiArray = [
- {
- "inputs":[
- {"name":"x","type":"uint256"},
- {"name":"y","type":"uint256"}
- ],
- "type":"constructor"
- },
- {
- "constant":true,
- "inputs":[],
- "name":"x",
- "outputs":[{"name":"","type":"bytes32"}],
- "type":"function"
- }
- ];
-
- var MyContract_ = web3.eth.contract(source);
- MyContract = web3.eth.contract(MyContract_.CONTRACT_NAME.info.abiDefinition);
- // deploy new contract
- var contractInstance = MyContract.new(
- 10,
- 11,
- {from: myAccount, gas: 1000000}
- );
-
.. index:: constructor;arguments
-Internally, constructor arguments are passed after the code of
-the contract itself, but you do not have to care about this
-if you use ``web3.js``.
+Internally, constructor arguments are passed :ref:`ABI encoded <ABI>` after the code of
+the contract itself, but you do not have to care about this if you use ``web3.js``.
If a contract wants to create another contract, the source code
(and the binary) of the created contract has to be known to the creator.
@@ -68,7 +40,7 @@ This means that cyclic creation dependencies are impossible.
::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
contract OwnedToken {
// TokenCreator is a contract type that is defined below.
@@ -80,11 +52,11 @@ This means that cyclic creation dependencies are impossible.
// This is the constructor which registers the
// creator and the assigned name.
- function OwnedToken(bytes32 _name) {
+ function OwnedToken(bytes32 _name) public {
// State variables are accessed via their name
// and not via e.g. this.owner. This also applies
// to functions and especially in the constructors,
- // you can only call them like that ("internall"),
+ // you can only call them like that ("internally"),
// because the contract itself does not exist yet.
owner = msg.sender;
// We do an explicit type conversion from `address`
@@ -95,7 +67,7 @@ This means that cyclic creation dependencies are impossible.
name = _name;
}
- function changeName(bytes32 newName) {
+ function changeName(bytes32 newName) public {
// Only the creator can alter the name --
// the comparison is possible since contracts
// are implicitly convertible to addresses.
@@ -103,7 +75,7 @@ This means that cyclic creation dependencies are impossible.
name = newName;
}
- function transfer(address newOwner) {
+ function transfer(address newOwner) public {
// Only the current owner can transfer the token.
if (msg.sender != owner) return;
// We also want to ask the creator if the transfer
@@ -118,25 +90,27 @@ This means that cyclic creation dependencies are impossible.
contract TokenCreator {
function createToken(bytes32 name)
+ public
returns (OwnedToken tokenAddress)
{
// Create a new Token contract and return its address.
// From the JavaScript side, the return type is simply
- // "address", as this is the closest type available in
+ // `address`, as this is the closest type available in
// the ABI.
return new OwnedToken(name);
}
- function changeName(OwnedToken tokenAddress, bytes32 name) {
- // Again, the external type of "tokenAddress" is
- // simply "address".
+ function changeName(OwnedToken tokenAddress, bytes32 name) public {
+ // Again, the external type of `tokenAddress` is
+ // simply `address`.
tokenAddress.changeName(name);
}
- function isTokenTransferOK(
- address currentOwner,
- address newOwner
- ) returns (bool ok) {
+ function isTokenTransferOK(address currentOwner, address newOwner)
+ public
+ view
+ returns (bool ok)
+ {
// Check some arbitrary condition.
address tokenAddress = msg.sender;
return (keccak256(newOwner) & 0xff) == (bytes20(tokenAddress) & 0xff);
@@ -199,10 +173,10 @@ return parameter list for functions.
::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
contract C {
- function f(uint a) private returns (uint b) { return a + 1; }
+ function f(uint a) private pure returns (uint b) { return a + 1; }
function setData(uint a) internal { data = a; }
uint public data;
}
@@ -213,37 +187,38 @@ In the following example, ``D``, can call ``c.getData()`` to retrieve the value
::
+ // This will not compile
+
pragma solidity ^0.4.0;
contract C {
uint private data;
function f(uint a) private returns(uint b) { return a + 1; }
- function setData(uint a) { data = a; }
+ function setData(uint a) public { data = a; }
function getData() public returns(uint) { return data; }
function compute(uint a, uint b) internal returns (uint) { return a+b; }
}
-
contract D {
- function readData() {
+ function readData() public {
C c = new C();
- uint local = c.f(7); // error: member "f" is not visible
+ uint local = c.f(7); // error: member `f` is not visible
c.setData(3);
local = c.getData();
- local = c.compute(3, 5); // error: member "compute" is not visible
+ local = c.compute(3, 5); // error: member `compute` is not visible
}
}
-
contract E is C {
- function g() {
+ function g() public {
C c = new C();
- uint val = compute(3, 5); // acces to internal member (from derivated to parent contract)
+ uint val = compute(3, 5); // access to internal member (from derived to parent contract)
}
}
.. index:: ! getter;function, ! function;getter
+.. _getter-functions:
Getter Functions
================
@@ -263,10 +238,9 @@ be done at declaration.
uint public data = 42;
}
-
contract Caller {
C c = new C();
- function f() {
+ function f() public {
uint local = c.data();
}
}
@@ -282,7 +256,7 @@ it is evaluated as a state variable. If it is accessed externally
contract C {
uint public data;
- function x() {
+ function x() public {
data = 3; // internal access
uint val = this.data(); // external access
}
@@ -305,7 +279,7 @@ The next example is a bit more complex:
It will generate a function of the following form::
- function data(uint arg1, bool arg2, uint arg3) returns (uint a, bytes3 b) {
+ function data(uint arg1, bool arg2, uint arg3) public returns (uint a, bytes3 b) {
a = data[arg1][arg2][arg3].a;
b = data[arg1][arg2][arg3].b;
}
@@ -330,13 +304,13 @@ inheritable properties of contracts and may be overridden by derived contracts.
pragma solidity ^0.4.11;
contract owned {
- function owned() { owner = msg.sender; }
+ function owned() public { owner = msg.sender; }
address owner;
// This contract only defines a modifier but does not use
- // it - it will be used in derived contracts.
+ // it: it will be used in derived contracts.
// The function body is inserted where the special symbol
- // "_;" in the definition of a modifier appears.
+ // `_;` in the definition of a modifier appears.
// This means that if the owner calls this function, the
// function is executed and otherwise, an exception is
// thrown.
@@ -346,18 +320,16 @@ inheritable properties of contracts and may be overridden by derived contracts.
}
}
-
contract mortal is owned {
- // This contract inherits the "onlyOwner"-modifier from
- // "owned" and applies it to the "close"-function, which
- // causes that calls to "close" only have an effect if
+ // This contract inherits the `onlyOwner` modifier from
+ // `owned` and applies it to the `close` function, which
+ // causes that calls to `close` only have an effect if
// they are made by the stored owner.
- function close() onlyOwner {
+ function close() public onlyOwner {
selfdestruct(owner);
}
}
-
contract priced {
// Modifiers can receive arguments:
modifier costs(uint price) {
@@ -367,21 +339,20 @@ inheritable properties of contracts and may be overridden by derived contracts.
}
}
-
contract Register is priced, owned {
mapping (address => bool) registeredAddresses;
uint price;
- function Register(uint initialPrice) { price = initialPrice; }
+ function Register(uint initialPrice) public { price = initialPrice; }
// It is important to also provide the
- // "payable" keyword here, otherwise the function will
+ // `payable` keyword here, otherwise the function will
// automatically reject all Ether sent to it.
- function register() payable costs(price) {
+ function register() public payable costs(price) {
registeredAddresses[msg.sender] = true;
}
- function changePrice(uint _price) onlyOwner {
+ function changePrice(uint _price) public onlyOwner {
price = _price;
}
}
@@ -396,10 +367,10 @@ inheritable properties of contracts and may be overridden by derived contracts.
}
/// This function is protected by a mutex, which means that
- /// reentrant calls from within msg.sender.call cannot call f again.
+ /// reentrant calls from within `msg.sender.call` cannot call `f` again.
/// The `return 7` statement assigns 7 to the return value but still
/// executes the statement `locked = false` in the modifier.
- function f() noReentrancy returns (uint) {
+ function f() public noReentrancy returns (uint) {
require(msg.sender.call());
return 7;
}
@@ -457,38 +428,89 @@ value types and strings.
bytes32 constant myHash = keccak256("abc");
}
+.. index:: ! functions
-.. _constant-functions:
+.. _functions:
-******************
-Constant Functions
-******************
+*********
+Functions
+*********
+
+.. index:: ! view function, function;view
-Functions can be declared constant in which case they promise not to modify the state.
+.. _view-functions:
+
+View Functions
+==============
+
+Functions can be declared ``view`` in which case they promise not to modify the state.
+
+The following statements are considered modifying the state:
+
+#. Writing to state variables.
+#. :ref:`Emitting events <events>`.
+#. :ref:`Creating other contracts <creating-contracts>`.
+#. Using ``selfdestruct``.
+#. Sending Ether via calls.
+#. Calling any function not marked ``view`` or ``pure``.
+#. Using low-level calls.
+#. Using inline assembly that contains certain opcodes.
::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
contract C {
- function f(uint a, uint b) constant returns (uint) {
- return a * (b + 42);
+ function f(uint a, uint b) public view returns (uint) {
+ return a * (b + 42) + now;
}
}
.. note::
- Getter methods are marked constant.
+ ``constant`` is an alias to ``view``.
+
+.. note::
+ Getter methods are marked ``view``.
.. warning::
- The compiler does not enforce yet that a constant method is not modifying state.
+ The compiler does not enforce yet that a ``view`` method is not modifying state.
+
+.. index:: ! pure function, function;pure
+
+.. _pure-functions:
+
+Pure Functions
+==============
+
+Functions can be declared ``pure`` in which case they promise not to read from or modify the state.
+
+In addition to the list of state modifying statements explained above, the following are considered reading from the state:
+
+#. Reading from state variables.
+#. Accessing ``this.balance`` or ``<address>.balance``.
+#. Accessing any of the members of ``block``, ``tx``, ``msg`` (with the exception of ``msg.sig`` and ``msg.data``).
+#. Calling any function not marked ``pure``.
+#. Using inline assembly that contains certain opcodes.
+
+::
+
+ pragma solidity ^0.4.16;
+
+ contract C {
+ function f(uint a, uint b) public pure returns (uint) {
+ return a * (b + 42);
+ }
+ }
+
+.. warning::
+ The compiler does not enforce yet that a ``pure`` method is not reading from the state.
.. index:: ! fallback function, function;fallback
.. _fallback-function:
-*****************
Fallback Function
-*****************
+=================
A contract can have exactly one unnamed function. This function cannot have
arguments and cannot return anything.
@@ -497,9 +519,11 @@ functions match the given function identifier (or if no data was supplied at
all).
Furthermore, this function is executed whenever the contract receives plain
-Ether (without data). In such a context, there is usually very little gas available to
-the function call (to be precise, 2300 gas), so it is important to make fallback functions as cheap as
-possible.
+Ether (without data). Additionally, in order to receive Ether, the fallback function
+must be marked ``payable``. If no such function exists, the contract cannot receive
+Ether through regular transactions.
+
+In such a context, there is usually very little gas available to the function call (to be precise, 2300 gas), so it is important to make fallback functions as cheap as possible. Note that the gas required by a transaction (as opposed to an internal call) that invokes the fallback function is much higher, because each transaction charges an additional amount of 21000 gas or more for things like signature checking.
In particular, the following operations will consume more gas than the stipend provided to a fallback function:
@@ -510,6 +534,10 @@ In particular, the following operations will consume more gas than the stipend p
Please ensure you test your fallback function thoroughly to ensure the execution cost is less than 2300 gas before deploying a contract.
+.. note::
+ Even though the fallback function cannot have arguments, one can still use ``msg.data`` to retrieve
+ any payload supplied with the call.
+
.. warning::
Contracts that receive Ether directly (without a function call, i.e. using ``send`` or ``transfer``)
but do not define a fallback function
@@ -517,6 +545,14 @@ Please ensure you test your fallback function thoroughly to ensure the execution
before Solidity v0.4.0). So if you want your contract to receive Ether,
you have to implement a fallback function.
+.. warning::
+ A contract without a payable fallback function can receive Ether as a recipient of a `coinbase transaction` (aka `miner block reward`)
+ or as a destination of a ``selfdestruct``.
+
+ A contract cannot react to such Ether transfers and thus also cannot reject them. This is a design choice of the EVM and Solidity cannot work around it.
+
+ It also means that ``this.balance`` can be higher than the sum of some manual accounting implemented in a contract (i.e. having a counter updated in the fallback function).
+
::
pragma solidity ^0.4.0;
@@ -525,9 +561,9 @@ Please ensure you test your fallback function thoroughly to ensure the execution
// This function is called for all messages sent to
// this contract (there is no other function).
// Sending Ether to this contract will cause an exception,
- // because the fallback function does not have the "payable"
+ // because the fallback function does not have the `payable`
// modifier.
- function() { x = 1; }
+ function() public { x = 1; }
uint x;
}
@@ -535,21 +571,101 @@ Please ensure you test your fallback function thoroughly to ensure the execution
// This contract keeps all Ether sent to it with no way
// to get it back.
contract Sink {
- function() payable { }
+ function() public payable { }
}
-
contract Caller {
- function callTest(Test test) {
+ function callTest(Test test) public {
test.call(0xabcdef01); // hash does not exist
// results in test.x becoming == 1.
- // The following call will fail, reject the
- // Ether and return false:
- test.send(2 ether);
+ // The following will not compile, but even
+ // if someone sends ether to that contract,
+ // the transaction will fail and reject the
+ // Ether.
+ //test.send(2 ether);
+ }
+ }
+
+.. index:: ! overload
+
+.. _overload-function:
+
+Function Overloading
+====================
+
+A Contract can have multiple functions of the same name but with different arguments.
+This also applies to inherited functions. The following example shows overloading of the
+``f`` function in the scope of contract ``A``.
+
+::
+
+ pragma solidity ^0.4.16;
+
+ contract A {
+ function f(uint _in) public pure returns (uint out) {
+ out = 1;
+ }
+
+ function f(uint _in, bytes32 _key) public pure returns (uint out) {
+ out = 2;
}
}
+Overloaded functions are also present in the external interface. It is an error if two
+externally visible functions differ by their Solidity types but not by their external types.
+
+::
+
+ // This will not compile
+ pragma solidity ^0.4.16;
+
+ contract A {
+ function f(B _in) public pure returns (B out) {
+ out = _in;
+ }
+
+ function f(address _in) public pure returns (address out) {
+ out = _in;
+ }
+ }
+
+ contract B {
+ }
+
+
+Both ``f`` function overloads above end up accepting the address type for the ABI although
+they are considered different inside Solidity.
+
+Overload resolution and Argument matching
+-----------------------------------------
+
+Overloaded functions are selected by matching the function declarations in the current scope
+to the arguments supplied in the function call. Functions are selected as overload candidates
+if all arguments can be implicitly converted to the expected types. If there is not exactly one
+candidate, resolution fails.
+
+.. note::
+ Return parameters are not taken into account for overload resolution.
+
+::
+
+ pragma solidity ^0.4.16;
+
+ contract A {
+ function f(uint8 _in) public pure returns (uint8 out) {
+ out = _in;
+ }
+
+ function f(uint256 _in) public pure returns (uint256 out) {
+ out = _in;
+ }
+ }
+
+Calling ``f(50)`` would create a type error since ``250`` can be implicitly converted both to ``uint8``
+and ``uint256`` types. On another hand ``f(256)`` would resolve to ``f(uint256)`` overload as ``256`` cannot be implicitly
+converted to ``uint8``.
+
.. index:: ! event
.. _events:
@@ -607,7 +723,7 @@ All non-indexed arguments will be stored in the data part of the log.
uint _value
);
- function deposit(bytes32 _id) payable {
+ function deposit(bytes32 _id) public payable {
// Any call to this function (even deeply nested) can
// be detected from the JavaScript API by filtering
// for `Deposit` to be called.
@@ -621,14 +737,14 @@ The use in the JavaScript API would be as follows:
var abi = /* abi as generated by the compiler */;
var ClientReceipt = web3.eth.contract(abi);
- var clientReceipt = ClientReceipt.at(0x123 /* address */);
+ var clientReceipt = ClientReceipt.at("0x1234...ab67" /* address */);
var event = clientReceipt.Deposit();
// watch for changes
event.watch(function(error, result){
// result will contain various information
- // including the argumets given to the Deposit
+ // including the argumets given to the `Deposit`
// call.
if (!error)
console.log(result);
@@ -653,12 +769,19 @@ as topics. The event call above can be performed in the same way as
::
- log3(
- msg.value,
- 0x50cb9fe53daa9737b786ab3646f04d0150dc50ef4e75f59509d83667ad5adb20,
- msg.sender,
- _id
- );
+ pragma solidity ^0.4.10;
+
+ contract C {
+ function f() public payable {
+ bytes32 _id = 0x420042;
+ log3(
+ bytes32(msg.value),
+ bytes32(0x50cb9fe53daa9737b786ab3646f04d0150dc50ef4e75f59509d83667ad5adb20),
+ bytes32(msg.sender),
+ _id
+ );
+ }
+ }
where the long hexadecimal number is equal to
``keccak256("Deposit(address,hash256,uint256)")``, the signature of the event.
@@ -693,15 +816,14 @@ Details are given in the following example.
::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
contract owned {
function owned() { owner = msg.sender; }
address owner;
}
-
- // Use "is" to derive from another contract. Derived
+ // Use `is` to derive from another contract. Derived
// contracts can access all non-private members including
// internal functions and state variables. These cannot be
// accessed externally via `this`, though.
@@ -711,28 +833,25 @@ Details are given in the following example.
}
}
-
// These abstract contracts are only provided to make the
// interface known to the compiler. Note the function
// without body. If a contract does not implement all
// functions it can only be used as an interface.
contract Config {
- function lookup(uint id) returns (address adr);
+ function lookup(uint id) public returns (address adr);
}
-
contract NameReg {
- function register(bytes32 name);
- function unregister();
+ function register(bytes32 name) public;
+ function unregister() public;
}
-
- // Multiple inheritance is possible. Note that "owned" is
- // also a base class of "mortal", yet there is only a single
- // instance of "owned" (as for virtual inheritance in C++).
+ // Multiple inheritance is possible. Note that `owned` is
+ // also a base class of `mortal`, yet there is only a single
+ // instance of `owned` (as for virtual inheritance in C++).
contract named is owned, mortal {
function named(bytes32 name) {
- Config config = Config(0xd5f9d8d94886e70b06e474c3fb14fd43e2f23970);
+ Config config = Config(0xD5f9D8D94886E70b06E474c3fB14Fd43E2f23970);
NameReg(config.lookup(1)).register(name);
}
@@ -741,9 +860,9 @@ Details are given in the following example.
// types of output parameters, that causes an error.
// Both local and message-based function calls take these overrides
// into account.
- function kill() {
+ function kill() public {
if (msg.sender == owner) {
- Config config = Config(0xd5f9d8d94886e70b06e474c3fb14fd43e2f23970);
+ Config config = Config(0xD5f9D8D94886E70b06E474c3fB14Fd43E2f23970);
NameReg(config.lookup(1)).unregister();
// It is still possible to call a specific
// overridden function.
@@ -752,16 +871,15 @@ Details are given in the following example.
}
}
-
// If a constructor takes an argument, it needs to be
// provided in the header (or modifier-invocation-style at
// the constructor of the derived contract (see below)).
contract PriceFeed is owned, mortal, named("GoldFeed") {
- function updateInfo(uint newInfo) {
+ function updateInfo(uint newInfo) public {
if (msg.sender == owner) info = newInfo;
}
- function get() constant returns(uint r) { return info; }
+ function get() public view returns(uint r) { return info; }
uint info;
}
@@ -772,23 +890,25 @@ seen in the following example::
pragma solidity ^0.4.0;
+ contract owned {
+ function owned() public { owner = msg.sender; }
+ address owner;
+ }
+
contract mortal is owned {
- function kill() {
+ function kill() public {
if (msg.sender == owner) selfdestruct(owner);
}
}
-
contract Base1 is mortal {
- function kill() { /* do cleanup 1 */ mortal.kill(); }
+ function kill() public { /* do cleanup 1 */ mortal.kill(); }
}
-
contract Base2 is mortal {
- function kill() { /* do cleanup 2 */ mortal.kill(); }
+ function kill() public { /* do cleanup 2 */ mortal.kill(); }
}
-
contract Final is Base1, Base2 {
}
@@ -799,32 +919,35 @@ derived override, but this function will bypass
pragma solidity ^0.4.0;
+ contract owned {
+ function owned() public { owner = msg.sender; }
+ address owner;
+ }
+
contract mortal is owned {
- function kill() {
+ function kill() public {
if (msg.sender == owner) selfdestruct(owner);
}
}
-
contract Base1 is mortal {
- function kill() { /* do cleanup 1 */ super.kill(); }
+ function kill() public { /* do cleanup 1 */ super.kill(); }
}
contract Base2 is mortal {
- function kill() { /* do cleanup 2 */ super.kill(); }
+ 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
-call this function on one of its base contracts. Rather, it
+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
@@ -842,12 +965,11 @@ the base constructors. This can be done in two ways::
contract Base {
uint x;
- function Base(uint _x) { x = _x; }
+ function Base(uint _x) public { x = _x; }
}
-
contract Derived is Base(7) {
- function Derived(uint _y) Base(_y * _y) {
+ function Derived(uint _y) Base(_y * _y) public {
}
}
@@ -878,6 +1000,8 @@ error "Linearization of inheritance graph impossible".
::
+ // This will not compile
+
pragma solidity ^0.4.0;
contract X {}
@@ -910,15 +1034,21 @@ Contract functions can lack an implementation as in the following example (note
pragma solidity ^0.4.0;
contract Feline {
- function utterance() returns (bytes32);
+ function utterance() public returns (bytes32);
}
-Such contracts cannot be compiled (even if they contain implemented functions alongside non-implemented functions), but they can be used as base contracts::
+Such contracts cannot be compiled (even if they contain
+implemented functions alongside non-implemented functions),
+but they can be used as base contracts::
pragma solidity ^0.4.0;
+ contract Feline {
+ function utterance() public returns (bytes32);
+ }
+
contract Cat is Feline {
- function utterance() returns (bytes32) { return "miaow"; }
+ function utterance() public returns (bytes32) { return "miaow"; }
}
If a contract inherits from an abstract contract and does not implement all non-implemented functions by overriding, it will itself be abstract.
@@ -946,8 +1076,10 @@ Interfaces are denoted by their own keyword:
::
+ pragma solidity ^0.4.11;
+
interface Token {
- function transfer(address recipient, uint amount);
+ function transfer(address recipient, uint amount) public;
}
Contracts can inherit interfaces as they would inherit other contracts.
@@ -968,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
@@ -979,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
@@ -990,7 +1126,7 @@ more advanced example to implement a set).
::
- pragma solidity ^0.4.11;
+ pragma solidity ^0.4.16;
library Set {
// We define a new struct datatype that will be used to
@@ -1001,9 +1137,10 @@ more advanced example to implement a set).
// reference" and thus only its storage address and not
// its contents is passed as part of the call. This is a
// special feature of library functions. It is idiomatic
- // to call the first parameter 'self', if the function can
+ // to call the first parameter `self`, if the function can
// be seen as a method of that object.
function insert(Data storage self, uint value)
+ public
returns (bool)
{
if (self.flags[value])
@@ -1013,6 +1150,7 @@ more advanced example to implement a set).
}
function remove(Data storage self, uint value)
+ public
returns (bool)
{
if (!self.flags[value])
@@ -1022,17 +1160,18 @@ more advanced example to implement a set).
}
function contains(Data storage self, uint value)
+ public
+ view
returns (bool)
{
return self.flags[value];
}
}
-
contract C {
Set.Data knownValues;
- function register(uint value) {
+ function register(uint value) public {
// The library functions can be called without a
// specific instance of the library, since the
// "instance" will be the current contract.
@@ -1042,7 +1181,7 @@ more advanced example to implement a set).
}
Of course, you do not have to follow this way to use
-libraries - they can also be used without defining struct
+libraries: they can also be used without defining struct
data types. Functions also work without any storage
reference parameters, and they can have multiple storage reference
parameters and in any position.
@@ -1052,7 +1191,7 @@ are all compiled as calls (``DELEGATECALL``) to an external
contract/library. If you use libraries, take care that an
actual external function call is performed.
``msg.sender``, ``msg.value`` and ``this`` will retain their values
-in this call, though (prior to Homestead, because of the use of `CALLCODE`, ``msg.sender`` and
+in this call, though (prior to Homestead, because of the use of ``CALLCODE``, ``msg.sender`` and
``msg.value`` changed, though).
The following example shows how to use memory types and
@@ -1061,19 +1200,19 @@ custom types without the overhead of external function calls:
::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
library BigInt {
struct bigint {
uint[] limbs;
}
- function fromUint(uint x) internal returns (bigint r) {
+ function fromUint(uint x) internal pure returns (bigint r) {
r.limbs = new uint[](1);
r.limbs[0] = x;
}
- function add(bigint _a, bigint _b) internal returns (bigint r) {
+ function add(bigint _a, bigint _b) internal pure returns (bigint r) {
r.limbs = new uint[](max(_a.limbs.length, _b.limbs.length));
uint carry = 0;
for (uint i = 0; i < r.limbs.length; ++i) {
@@ -1095,20 +1234,19 @@ custom types without the overhead of external function calls:
}
}
- function limb(bigint _a, uint _limb) internal returns (uint) {
+ function limb(bigint _a, uint _limb) internal pure returns (uint) {
return _limb < _a.limbs.length ? _a.limbs[_limb] : 0;
}
- function max(uint a, uint b) private returns (uint) {
+ function max(uint a, uint b) private pure returns (uint) {
return a > b ? a : b;
}
}
-
contract C {
using BigInt for BigInt.bigint;
- function f() {
+ function f() public pure {
var x = BigInt.fromUint(7);
var y = BigInt.fromUint(uint(-1));
var z = x.add(y);
@@ -1134,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:
@@ -1166,13 +1328,14 @@ available without having to add further code.
Let us rewrite the set example from the
:ref:`libraries` in this way::
- pragma solidity ^0.4.11;
+ pragma solidity ^0.4.16;
// This is the same code as before, just without comments
library Set {
struct Data { mapping(uint => bool) flags; }
function insert(Data storage self, uint value)
+ public
returns (bool)
{
if (self.flags[value])
@@ -1182,6 +1345,7 @@ Let us rewrite the set example from the
}
function remove(Data storage self, uint value)
+ public
returns (bool)
{
if (!self.flags[value])
@@ -1191,48 +1355,52 @@ Let us rewrite the set example from the
}
function contains(Data storage self, uint value)
+ public
+ view
returns (bool)
{
return self.flags[value];
}
}
-
contract C {
using Set for Set.Data; // this is the crucial change
Set.Data knownValues;
- function register(uint value) {
+ function register(uint value) public {
// Here, all variables of type Set.Data have
// corresponding member functions.
// The following function call is identical to
- // Set.insert(knownValues, value)
+ // `Set.insert(knownValues, value)`
require(knownValues.insert(value));
}
}
It is also possible to extend elementary types in that way::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
library Search {
- function indexOf(uint[] storage self, uint value) returns (uint) {
+ function indexOf(uint[] storage self, uint value)
+ public
+ view
+ returns (uint)
+ {
for (uint i = 0; i < self.length; i++)
if (self[i] == value) return i;
return uint(-1);
}
}
-
contract C {
using Search for uint[];
uint[] data;
- function append(uint value) {
+ function append(uint value) public {
data.push(value);
}
- function replace(uint _old, uint _new) {
+ function replace(uint _old, uint _new) public {
// This performs the library function call
uint index = data.indexOf(_old);
if (index == uint(-1))
diff --git a/docs/contributing.rst b/docs/contributing.rst
index 1f869dbb..a5efba8b 100644
--- a/docs/contributing.rst
+++ b/docs/contributing.rst
@@ -50,8 +50,10 @@ and instead, ``git rebase`` your branch.
Additionally, if you are writing a new feature, please ensure you write appropriate
Boost test cases and place them under ``test/``.
-However, if you are making a larger change, please consult with the Gitter
-channel, first.
+However, if you are making a larger change, please consult with the `Solidity Development Gitter channel
+<https://gitter.im/ethereum/solidity-dev>`_ (different from the one mentioned above, this on is
+focused on compiler and language development instead of language use) first.
+
Finally, please make sure you respect the `coding standards
<https://raw.githubusercontent.com/ethereum/cpp-ethereum/develop/CodingStandards.txt>`_
@@ -64,13 +66,39 @@ Running the compiler tests
==========================
Solidity includes different types of tests. They are included in the application
-called ``soltest``. Some of them require the ``cpp-ethereum`` client in testing mode.
+called ``soltest``. Some of them require the ``cpp-ethereum`` client in testing mode,
+some others require ``libz3`` to be installed.
+
+To disable the z3 tests, use ``./build/test/soltest -- --no-smt`` and
+to run a subset of the tests that do not require ``cpp-ethereum``, use ``./build/test/soltest -- --no-ipc``.
-To run ``cpp-ethereum`` in testing mode: ``eth --test -d /tmp/testeth``.
+For all other tests, you need to install `cpp-ethereum <https://github.com/ethereum/cpp-ethereum/releases/download/solidityTester/eth>`_ and run it in testing mode: ``eth --test -d /tmp/testeth``.
-To run the tests: ``soltest -- --ipcpath /tmp/testeth/geth.ipc``.
+Then you run the actual tests: ``./build/test/soltest -- --ipcpath /tmp/testeth/geth.ipc``.
To run a subset of tests, filters can be used:
``soltest -t TestSuite/TestName -- --ipcpath /tmp/testeth/geth.ipc``, where ``TestName`` can be a wildcard ``*``.
-Alternatively, there is a testing script at ``scripts/test.sh`` which executes all tests.
+Alternatively, there is a testing script at ``scripts/test.sh`` which executes all tests and runs
+``cpp-ethereum`` automatically if it is in the path (but does not download it).
+
+Travis CI even runs some additional tests (including ``solc-js`` and testing third party Solidity frameworks) that require compiling the Emscripten target.
+
+Whiskers
+========
+
+*Whiskers* is a templating system similar to `Mustache <https://mustache.github.io>`_. It is used by the
+compiler in various places to aid readability, and thus maintainability and verifiability, of the code.
+
+The syntax comes with a substantial difference to Mustache: the template markers ``{{`` and ``}}`` are
+replaced by ``<`` and ``>`` in order to aid parsing and avoid conflicts with :ref:`inline-assembly`
+(The symbols ``<`` and ``>`` are invalid in inline assembly, while ``{`` and ``}`` are used to delimit blocks).
+Another limitation is that lists are only resolved one depth and they will not recurse. This may change in the future.
+
+A rough specification is the following:
+
+Any occurrence of ``<name>`` is replaced by the string-value of the supplied variable ``name`` without any
+escaping and without iterated replacements. An area can be delimited by ``<#name>...</name>``. It is replaced
+by as many concatenations of its contents as there were sets of variables supplied to the template system,
+each time replacing any ``<inner>`` items by their respective value. Top-level variables can also be used
+inside such areas.
diff --git a/docs/control-structures.rst b/docs/control-structures.rst
index a2d34274..7be92cfa 100644
--- a/docs/control-structures.rst
+++ b/docs/control-structures.rst
@@ -20,8 +20,10 @@ For example, suppose we want our contract to
accept one kind of external calls with two integers, we would write
something like::
+ pragma solidity ^0.4.16;
+
contract Simple {
- function taker(uint _a, uint _b) {
+ function taker(uint _a, uint _b) public pure {
// do something with _a and _b.
}
}
@@ -34,8 +36,14 @@ The output parameters can be declared with the same syntax after the
the sum and the product of the two given integers, then we would
write::
+ pragma solidity ^0.4.16;
+
contract Simple {
- function arithmetics(uint _a, uint _b) returns (uint o_sum, uint o_product) {
+ function arithmetics(uint _a, uint _b)
+ public
+ pure
+ returns (uint o_sum, uint o_product)
+ {
o_sum = _a + _b;
o_product = _a * _b;
}
@@ -91,9 +99,11 @@ Internal Function Calls
Functions of the current contract can be called directly ("internally"), also recursively, as seen in
this nonsensical example::
+ pragma solidity ^0.4.16;
+
contract C {
- function g(uint a) returns (uint ret) { return f(); }
- function f() returns (uint ret) { return g(7) + f(); }
+ function g(uint a) public pure returns (uint ret) { return f(); }
+ function f() internal pure returns (uint ret) { return g(7) + f(); }
}
These function calls are translated into simple jumps inside the EVM. This has
@@ -116,15 +126,16 @@ all function arguments have to be copied to memory.
When calling functions of other contracts, the amount of Wei sent with the call and
the gas can be specified with special options ``.value()`` and ``.gas()``, respectively::
+ pragma solidity ^0.4.0;
+
contract InfoFeed {
- function info() payable returns (uint ret) { return 42; }
+ function info() public payable returns (uint ret) { return 42; }
}
-
contract Consumer {
InfoFeed feed;
- function setFeed(address addr) { feed = InfoFeed(addr); }
- function callFeed() { feed.info.value(10).gas(800)(); }
+ function setFeed(address addr) public { feed = InfoFeed(addr); }
+ function callFeed() public { feed.info.value(10).gas(800)(); }
}
The modifier ``payable`` has to be used for ``info``, because otherwise, the `.value()`
@@ -173,9 +184,11 @@ parameters from the function declaration, but can be in arbitrary order.
pragma solidity ^0.4.0;
contract C {
- function f(uint key, uint value) { ... }
+ function f(uint key, uint value) public {
+ // ...
+ }
- function g() {
+ function g() public {
// named arguments
f({value: 2, key: 3});
}
@@ -185,19 +198,19 @@ Omitted Function Parameter Names
--------------------------------
The names of unused parameters (especially return parameters) can be omitted.
-Those names will still be present on the stack, but they are inaccessible.
+Those parameters will still be present on the stack, but they are inaccessible.
::
- pragma solidity ^0.4.0;
+ pragma solidity ^0.4.16;
contract C {
// omitted name for parameter
- function func(uint k, uint) returns(uint) {
+ function func(uint k, uint) public pure returns(uint) {
return k;
}
}
-
+
.. index:: ! new, contracts;creating
@@ -216,29 +229,29 @@ creation-dependencies are not possible.
contract D {
uint x;
- function D(uint a) payable {
+ function D(uint a) public payable {
x = a;
}
}
-
contract C {
D d = new D(4); // will be executed as part of C's constructor
- function createD(uint arg) {
+ function createD(uint arg) public {
D newD = new D(arg);
}
- function createAndEndowD(uint arg, uint amount) {
+ function createAndEndowD(uint arg, uint amount) public payable {
// Send ether along with the creation
D newD = (new D).value(amount)(arg);
}
}
-As seen in the example, it is possible to forward Ether to the creation using the ``.value()`` option,
-but it is not possible to limit the amount of gas. If the creation fails
-(due to out-of-stack, not enough balance or other problems), an exception
-is thrown.
+As seen in the example, it is possible to forward Ether while creating
+an instance of ``D`` using the ``.value()`` option, but it is not possible
+to limit the amount of gas.
+If the creation fails (due to out-of-stack, not enough balance or other problems),
+an exception is thrown.
Order of Evaluation of Expressions
==================================
@@ -261,14 +274,16 @@ Destructuring Assignments and Returning Multiple Values
Solidity internally allows tuple types, i.e. a list of objects of potentially different types whose size is a constant at compile-time. Those tuples can be used to return multiple values at the same time and also assign them to multiple variables (or LValues in general) at the same time::
+ pragma solidity ^0.4.16;
+
contract C {
uint[] data;
- function f() returns (uint, bool, uint) {
+ function f() public pure returns (uint, bool, uint) {
return (7, true, 2);
}
- function g() {
+ function g() public {
// Declares and assigns the variables. Specifying the type explicitly is not possible.
var (x, b, y) = f();
// Assigns to a pre-existing variable.
@@ -280,6 +295,7 @@ Solidity internally allows tuple types, i.e. a list of objects of potentially di
// the rest of the values are discarded.
(data.length,) = f(); // Sets the length to 7
// The same can be done on the left side.
+ // If the tuple begins in an empty component, the beginning values are discarded.
(,data[3]) = f(); // Sets data[3] to 2
// Components can only be left out at the left-hand-side of assignments, with
// one exception:
@@ -313,10 +329,12 @@ This happens because Solidity inherits its scoping rules from JavaScript.
This is in contrast to many languages where variables are only scoped where they are declared until the end of the semantic block.
As a result, the following code is illegal and cause the compiler to throw an error, ``Identifier already declared``::
- pragma solidity ^0.4.0;
+ // This will not compile
+
+ pragma solidity ^0.4.16;
contract ScopingErrors {
- function scoping() {
+ function scoping() public {
uint i = 0;
while (i++ < 1) {
@@ -328,7 +346,7 @@ As a result, the following code is illegal and cause the compiler to throw an er
}
}
- function minimalScoping() {
+ function minimalScoping() public {
{
uint same2 = 0;
}
@@ -338,7 +356,7 @@ As a result, the following code is illegal and cause the compiler to throw an er
}
}
- function forLoopScoping() {
+ function forLoopScoping() public {
for (uint same3 = 0; same3 < 1; same3++) {
}
@@ -350,66 +368,91 @@ As a result, the following code is illegal and cause the compiler to throw an er
In addition to this, if a variable is declared, it will be initialized at the beginning of the function to its default value.
As a result, the following code is legal, despite being poorly written::
- function foo() returns (uint) {
- // baz is implicitly initialized as 0
- uint bar = 5;
- if (true) {
- bar += baz;
- } else {
- uint baz = 10;// never executes
+ pragma solidity ^0.4.0;
+
+ contract C {
+ function foo() public pure returns (uint) {
+ // baz is implicitly initialized as 0
+ uint bar = 5;
+ if (true) {
+ bar += baz;
+ } else {
+ uint baz = 10;// never executes
+ }
+ return bar;// returns 5
}
- return bar;// returns 5
}
-.. index:: ! exception, ! throw
+.. index:: ! exception, ! throw, ! assert, ! require, ! revert
-Exceptions
-==========
+Error handling: Assert, Require, Revert and Exceptions
+======================================================
-There are some cases where exceptions are thrown automatically (see below). You can use the ``throw`` instruction to throw an exception manually. The effect of an exception is that the currently executing call is stopped and reverted (i.e. all changes to the state and balances are undone) and the exception is also "bubbled up" through Solidity function calls (exceptions are ``send`` and the low-level functions ``call``, ``delegatecall`` and ``callcode``, those return ``false`` in case of an exception).
+Solidity uses state-reverting exceptions to handle errors. Such an exception will undo all changes made to the
+state in the current call (and all its sub-calls) and also flag an error to the caller.
+The convenience functions ``assert`` and ``require`` can be used to check for conditions and throw an exception
+if the condition is not met. The ``assert`` function should only be used to test for internal errors, and to check invariants.
+The ``require`` function should be used to ensure valid conditions, such as inputs, or contract state variables are met, or to validate return values from calls to external contracts.
+If used properly, analysis tools can evaluate your contract to identify the conditions and function calls which will reach a failing ``assert``. Properly functioning code should never reach a failing assert statement; if this happens there is a bug in your contract which you should fix.
+
+There are two other ways to trigger exceptions: The ``revert`` function can be used to flag an error and
+revert the current call. In the future it might be possible to also include details about the error
+in a call to ``revert``. The ``throw`` keyword can also be used as an alternative to ``revert()``.
+
+.. note::
+ From version 0.4.13 the ``throw`` keyword is deprecated and will be phased out in the future.
+
+When exceptions happen in a sub-call, they "bubble up" (i.e. exceptions are rethrown) automatically. Exceptions to this rule are ``send``
+and the low-level functions ``call``, ``delegatecall`` and ``callcode`` -- those return ``false`` in case
+of an exception instead of "bubbling up".
+
+.. warning::
+ The low-level ``call``, ``delegatecall`` and ``callcode`` will return success if the called account is non-existent, as part of the design of EVM. Existence must be checked prior to calling if desired.
Catching exceptions is not yet possible.
-In the following example, we show how ``throw`` can be used to easily revert an Ether transfer and also how to check the return value of ``send``::
+In the following example, you can see how ``require`` can be used to easily check conditions on inputs
+and how ``assert`` can be used for internal error checking::
pragma solidity ^0.4.0;
contract Sharer {
- function sendHalf(address addr) payable returns (uint balance) {
- if (!addr.send(msg.value / 2))
- throw; // also reverts the transfer to Sharer
+ function sendHalf(address addr) public payable returns (uint balance) {
+ require(msg.value % 2 == 0); // Only allow even numbers
+ uint balanceBeforeTransfer = this.balance;
+ addr.transfer(msg.value / 2);
+ // Since transfer throws an exception on failure and
+ // cannot call back here, there should be no way for us to
+ // still have half of the money.
+ assert(this.balance == balanceBeforeTransfer - msg.value / 2);
return this.balance;
}
}
-Currently, Solidity automatically generates a runtime exception in the following situations:
+An ``assert``-style exception is generated in the following situations:
#. If you access an array at a too large or negative index (i.e. ``x[i]`` where ``i >= x.length`` or ``i < 0``).
#. If you access a fixed-length ``bytesN`` at a too large or negative index.
-#. If you call a function via a message call but it does not finish properly (i.e. it runs out of gas, has no matching function, or throws an exception itself), except when a low level operation ``call``, ``send``, ``delegatecall`` or ``callcode`` is used. The low level operations never throw exceptions but indicate failures by returning ``false``.
-#. If you create a contract using the ``new`` keyword but the contract creation does not finish properly (see above for the definition of "not finish properly").
#. If you divide or modulo by zero (e.g. ``5 / 0`` or ``23 % 0``).
#. If you shift by a negative amount.
#. If you convert a value too big or negative into an enum type.
-#. If you perform an external function call targeting a contract that contains no code.
-#. If your contract receives Ether via a public function without ``payable`` modifier (including the constructor and the fallback function).
-#. If your contract receives Ether via a public getter function.
#. If you call a zero-initialized variable of internal function type.
-#. If a ``.transfer()`` fails.
#. If you call ``assert`` with an argument that evaluates to false.
-While a user-provided exception is generated in the following situations:
+A ``require``-style exception is generated in the following situations:
#. Calling ``throw``.
#. Calling ``require`` with an argument that evaluates to ``false``.
+#. If you call a function via a message call but it does not finish properly (i.e. it runs out of gas, has no matching function, or throws an exception itself), except when a low level operation ``call``, ``send``, ``delegatecall`` or ``callcode`` is used. The low level operations never throw exceptions but indicate failures by returning ``false``.
+#. If you create a contract using the ``new`` keyword but the contract creation does not finish properly (see above for the definition of "not finish properly").
+#. If you perform an external function call targeting a contract that contains no code.
+#. If your contract receives Ether via a public function without ``payable`` modifier (including the constructor and the fallback function).
+#. If your contract receives Ether via a public getter function.
+#. If a ``.transfer()`` fails.
-Internally, Solidity performs a revert operation (instruction ``0xfd``) when a user-provided exception is thrown or the condition of
-a ``require`` call is not met. In contrast, it performs an invalid operation
-(instruction ``0xfe``) if a runtime exception is encountered or the condition of an ``assert`` call is not met. In both cases, this causes
-the EVM to revert all changes made to the state. The reason for this is that there is no safe way to continue execution, because an expected effect
+Internally, Solidity performs a revert operation (instruction ``0xfd``) for a ``require``-style exception and executes an invalid operation
+(instruction ``0xfe``) to throw an ``assert``-style exception. In both cases, this causes
+the EVM to revert all changes made to the state. The reason for reverting is that there is no safe way to continue execution, because an expected effect
did not occur. Because we want to retain the atomicity of transactions, the safest thing to do is to revert all changes and make the whole transaction
-(or at least call) without effect.
-
-If contracts are written so that ``assert`` is only used to test internal conditions and ``require``
-is used in case of malformed input, a formal analysis tool that verifies that the invalid
-opcode can never be reached can be used to check for the absence of errors assuming valid inputs.
+(or at least call) without effect. Note that ``assert``-style exceptions consume all gas available to the call, while
+``require``-style exceptions will not consume any gas starting from the Metropolis release.
diff --git a/docs/frequently-asked-questions.rst b/docs/frequently-asked-questions.rst
index 03ee8388..a6bead29 100644
--- a/docs/frequently-asked-questions.rst
+++ b/docs/frequently-asked-questions.rst
@@ -39,12 +39,13 @@ This is just the bytecode "data" sent along with the request.
Is there a decompiler available?
================================
-There is no decompiler to Solidity. This is in principle possible
-to some degree, but for example variable names will be lost and
-great effort will be necessary to make it look similar to
-the original source code.
+There is no exact decompiler to Solidity, but
+`Porosity <https://github.com/comaeio/porosity>`_ is close.
+Because some information like variable names, comments, and
+source code formatting is lost in the compilation process,
+it is not possible to completely recover the original source code.
-Bytecode can be decompiled to opcodes, a service that is provided by
+Bytecode can be disassembled to opcodes, a service that is provided by
several blockchain explorers.
Contracts on the blockchain should have their original source
@@ -103,11 +104,6 @@ This is a limitation of the EVM and will be solved with the next protocol update
Returning variably-sized data as part of an external transaction or call is fine.
-How do you represent ``double``/``float`` in Solidity?
-======================================================
-
-This is not yet possible.
-
Is it possible to in-line initialize an array like so: ``string[] myarray = ["a", "b"];``
=========================================================================================
@@ -116,31 +112,15 @@ array in the return statement. Pretty cool, huh?
Example::
+ pragma solidity ^0.4.16;
+
contract C {
- function f() returns (uint8[5]) {
+ function f() public pure returns (uint8[5]) {
string[4] memory adaArr = ["This", "is", "an", "array"];
return ([1, 2, 3, 4, 5]);
}
}
-Are timestamps (``now,`` ``block.timestamp``) reliable?
-=======================================================
-
-This depends on what you mean by "reliable".
-In general, they are supplied by miners and are therefore vulnerable.
-
-Unless someone really messes up the blockchain or the clock on
-your computer, you can make the following assumptions:
-
-You publish a transaction at a time X, this transaction contains same
-code that calls ``now`` and is included in a block whose timestamp is Y
-and this block is included into the canonical chain (published) at a time Z.
-
-The value of ``now`` will be identical to Y and X <= Y <= Z.
-
-Never use ``now`` or ``block.hash`` as a source of randomness, unless you know
-what you are doing!
-
Can a contract function return a ``struct``?
============================================
@@ -153,37 +133,6 @@ Enums are not supported by the ABI, they are just supported by Solidity.
You have to do the mapping yourself for now, we might provide some help
later.
-What is the deal with ``function () { ... }`` inside Solidity contracts? How can a function not have a name?
-============================================================================================================
-
-This function is called "fallback function" and it
-is called when someone just sent Ether to the contract without
-providing any data or if someone messed up the types so that they tried to
-call a function that does not exist.
-
-The default behaviour (if no fallback function is explicitly given) in
-these situations is to throw an exception.
-
-If the contract is meant to receive Ether with simple transfers, you
-should implement the fallback function as
-
-``function() payable { }``
-
-Another use of the fallback function is to e.g. register that your
-contract received ether by using an event.
-
-*Attention*: If you implement the fallback function take care that it uses as
-little gas as possible, because ``send()`` will only supply a limited amount.
-
-Is it possible to pass arguments to the fallback function?
-==========================================================
-
-The fallback function cannot take parameters.
-
-Under special circumstances, you can send data. If you take care
-that none of the other functions is invoked, you can access the data
-by ``msg.data``.
-
Can state variables be initialized in-line?
===========================================
@@ -192,6 +141,8 @@ should be noted that you must declare them as static memory arrays.
Examples::
+ pragma solidity ^0.4.0;
+
contract C {
struct S {
uint a;
@@ -200,10 +151,9 @@ Examples::
S public x = S(1, 2);
string name = "Ada";
- string[4] memory adaArr = ["This", "is", "an", "array"];
+ string[4] adaArr = ["This", "is", "an", "array"];
}
-
contract D {
C c = new C();
}
@@ -227,13 +177,6 @@ Better use ``for (uint i = 0; i < a.length...``
See `struct_and_for_loop_tester.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/65_struct_and_for_loop_tester.sol>`_.
-What character set does Solidity use?
-=====================================
-
-Solidity is character set agnostic concerning strings in the source code, although
-UTF-8 is recommended. Identifiers (variables, functions, ...) can only use
-ASCII.
-
What are some examples of basic string manipulation (``substring``, ``indexOf``, ``charAt``, etc)?
==================================================================================================
@@ -243,14 +186,16 @@ which will be extended in the future. In addition, Arachnid has written `solidit
For now, if you want to modify a string (even when you only want to know its length),
you should always convert it to a ``bytes`` first::
+ pragma solidity ^0.4.0;
+
contract C {
string s;
- function append(byte c) {
+ function append(byte c) public {
bytes(s).push(c);
}
- function set(uint i, byte c) {
+ function set(uint i, byte c) public {
bytes(s)[i] = c;
}
}
@@ -288,10 +233,14 @@ situation.
If you do not want to throw, you can return a pair::
+ pragma solidity ^0.4.16;
+
contract C {
uint[] counters;
function getCounter(uint index)
+ public
+ view
returns (uint counter, bool error) {
if (index >= counters.length)
return (0, true);
@@ -299,12 +248,12 @@ If you do not want to throw, you can return a pair::
return (counters[index], false);
}
- function checkCounter(uint index) {
+ function checkCounter(uint index) public view {
var (counter, error) = getCounter(index);
if (error) {
- ...
+ // ...
} else {
- ...
+ // ...
}
}
}
@@ -358,24 +307,27 @@ There are defaults for the storage location depending on which type
of variable it concerns:
* state variables are always in storage
-* function arguments are always in memory
-* local variables always reference storage
+* function arguments are in memory by default
+* local variables of struct, array or mapping type reference storage by default
+* local variables of value type (i.e. neither array, nor struct nor mapping) are stored in the stack
Example::
+ pragma solidity ^0.4.0;
+
contract C {
uint[] data1;
uint[] data2;
- function appendOne() {
+ function appendOne() public {
append(data1);
}
- function appendTwo() {
+ function appendTwo() public {
append(data2);
}
- function append(uint[] storage d) {
+ function append(uint[] storage d) internal {
d.push(1);
}
}
@@ -393,11 +345,14 @@ A common mistake is to declare a local variable and assume that it will
be created in memory, although it will be created in storage::
/// THIS CONTRACT CONTAINS AN ERROR
+
+ pragma solidity ^0.4.0;
+
contract C {
uint someVariable;
uint[] data;
- function f() {
+ function f() public {
uint[] x;
x.push(2);
data = x;
@@ -417,33 +372,18 @@ slot ``0``) is modified by ``x.push(2)``.
The correct way to do this is the following::
+ pragma solidity ^0.4.0;
+
contract C {
uint someVariable;
uint[] data;
- function f() {
+ function f() public {
uint[] x = data;
x.push(2);
}
}
-What is the difference between ``bytes`` and ``byte[]``?
-========================================================
-
-``bytes`` is usually more efficient: When used as arguments to functions (i.e. in
-CALLDATA) or in memory, every single element of a ``byte[]`` is padded to 32
-bytes which wastes 31 bytes per element.
-
-Is it possible to send a value while calling an overloaded function?
-====================================================================
-
-It's a known missing feature. https://www.pivotaltracker.com/story/show/92020468
-as part of https://www.pivotaltracker.com/n/projects/1189488
-
-Best solution currently see is to introduce a special case for gas and value and
-just re-check whether they are present at the point of overload resolution.
-
-
******************
Advanced Questions
******************
@@ -489,36 +429,19 @@ Note2: Optimizing storage access can pull the gas costs down considerably, becau
currently do not work across loops and also have a problem with bounds checking.
You might get much better results in the future, though.
-What does ``p.recipient.call.value(p.amount)(p.data)`` do?
-==========================================================
-
-Every external function call in Solidity can be modified in two ways:
-
-1. You can add Ether together with the call
-2. You can limit the amount of gas available to the call
-
-This is done by "calling a function on the function":
-
-``f.gas(2).value(20)()`` calls the modified function ``f`` and thereby sending 20
-Wei and limiting the gas to 2 (so this function call will most likely go out of
-gas and return your 20 Wei).
-
-In the above example, the low-level function ``call`` is used to invoke another
-contract with ``p.data`` as payload and ``p.amount`` Wei is sent with that call.
-
What happens to a ``struct``'s mapping when copying over a ``struct``?
======================================================================
This is a very interesting question. Suppose that we have a contract field set up like such::
- struct user {
- mapping(string => address) usedContracts;
+ struct User {
+ mapping(string => string) comments;
}
- function somefunction {
- user user1;
- user1.usedContracts["Hello"] = "World";
- user user2 = user1;
+ function somefunction public {
+ User user1;
+ user1.comments["Hello"] = "World";
+ User user2 = user1;
}
In this case, the mapping of the struct being copied over into the userList is ignored as there is no "list of mapped keys".
@@ -533,15 +456,16 @@ In the case of a ``contract A`` calling a new instance of ``contract B``, parent
You will need to make sure that you have both contracts aware of each other's presence and that ``contract B`` has a ``payable`` constructor.
In this example::
+ pragma solidity ^0.4.0;
+
contract B {
- function B() payable {}
+ function B() public payable {}
}
-
contract A {
address child;
- function test() {
+ function test() public {
child = (new B).value(10)(); //construct a new B with 10 wei
}
}
@@ -580,19 +504,21 @@ Can a contract pass an array (static size) or string or ``bytes`` (dynamic size)
Sure. Take care that if you cross the memory / storage boundary,
independent copies will be created::
+ pragma solidity ^0.4.16;
+
contract C {
uint[20] x;
- function f() {
+ function f() public {
g(x);
h(x);
}
- function g(uint[20] y) {
+ function g(uint[20] y) internal pure {
y[2] = 3;
}
- function h(uint[20] storage y) {
+ function h(uint[20] storage y) internal {
y[3] = 4;