docs: describe when and how overflown values are cleaned

This commit is contained in:
Yoichi Hirai 2016-11-10 15:56:12 +01:00
parent fb9babce54
commit 7959ee49be
No known key found for this signature in database
GPG Key ID: E7B75D080FCF7992
2 changed files with 52 additions and 2 deletions

View File

@ -5,7 +5,7 @@ Features:
Bugfixes:
* Type checker: string literals that are not valid UTF-8 cannot be converted to string type
* Code generator: higher bits in a boolean argument are ignored.
* Code generator: any non-zero value given as a boolean argument is now converted into 1.
### 0.4.6 (2016-11-22)

View File

@ -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
*****************