diff options
author | Yoichi Hirai <i@yoichihirai.com> | 2016-11-10 22:56:12 +0800 |
---|---|---|
committer | Yoichi Hirai <i@yoichihirai.com> | 2016-12-01 00:41:58 +0800 |
commit | 7959ee49beb664238e58dcb589f386b2dff7438c (patch) | |
tree | 66b0b33138e78c85c15861616ddb53912e34c713 /docs/miscellaneous.rst | |
parent | fb9babce54f76251b9616f192822e0c015411159 (diff) | |
download | dexon-solidity-7959ee49beb664238e58dcb589f386b2dff7438c.tar.gz dexon-solidity-7959ee49beb664238e58dcb589f386b2dff7438c.tar.zst dexon-solidity-7959ee49beb664238e58dcb589f386b2dff7438c.zip |
docs: describe when and how overflown values are cleaned
Diffstat (limited to 'docs/miscellaneous.rst')
-rw-r--r-- | docs/miscellaneous.rst | 52 |
1 files changed, 51 insertions, 1 deletions
diff --git a/docs/miscellaneous.rst b/docs/miscellaneous.rst index 9f733979..7e9cee44 100644 --- a/docs/miscellaneous.rst +++ b/docs/miscellaneous.rst @@ -56,6 +56,8 @@ So for the following contract snippet:: The position of ``data[4][9].b`` is at ``keccak256(uint256(9) . keccak256(uint256(4) . uint256(1))) + 1``. +.. index: memory layout + **************** Layout in Memory **************** @@ -72,7 +74,8 @@ Solidity always places new objects at the free memory pointer and memory is neve .. warning:: There are some operations in Solidity that need a temporary memory area larger than 64 bytes and therefore will not fit into the scratch space. They will be placed where the free memory points to, but given their short lifecycle, the pointer is not updated. The memory may or may not be zeroed out. Because of this, one shouldn't expect the free memory to be zeroed out. -.. index: memory layout + +.. index: calldata layout ******************* Layout of Call Data @@ -85,6 +88,53 @@ specification ABI specification requires arguments to be padded to multiples of 32 bytes. The internal function calls use a different convention. + +.. index: overflow + +**************************************** +Internals - Cleaning Up Overflows in EVM +**************************************** + +When a value is shorter than 256-bit, sometimes the remaining bits +must be cleaned. +The Solidity compiler is designed to clean such remaining bits before any operations +that might be broken by the garbage in the remaining bits. For +example, before writing a value to the memory, the remaining bits need +to be cleared because the memory contents can be used for computing +hashes or sent as the data of a message call. Similarly, before +storing a value in the storage, the remaining bits need to be cleaned +because otherwise the garbled value can be observed. + +On the other hand, we do not clean the bits if the immediately +following operation is not affected. For instance, since any non-zero +value is considered ``true`` by ``JUMPI`` instruction, we do not clean +the boolean values before they are used as the condition for +``JUMPI``. + +Different types have different rules for cleaning up overflows: + ++---------------+---------------+------------------+ +|Type |Cleaned Form |Overflow Means | ++===============+===============+==================+ +|enum of n |0 until n - 1 |exception | +|members | | | ++---------------+---------------+------------------+ +|bool |0 or 1 |zero or nonzero | ++---------------+---------------+------------------+ +|signed integers|sign-extended |currently silently| +| |word |wraps; in the | +| | |future exceptions | +| | |will be thrown | +| | | | +| | | | ++---------------+---------------+------------------+ +|unsigned |higher bits |currently silently| +|integers |zeroed |wraps; in the | +| | |future exceptions | +| | |will be thrown | ++---------------+---------------+------------------+ + + ***************** Esoteric Features ***************** |