mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
docs: describe when and how overflown values are cleaned
This commit is contained in:
parent
fb9babce54
commit
7959ee49be
@ -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)
|
||||
|
||||
|
@ -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
|
||||
*****************
|
||||
|
Loading…
Reference in New Issue
Block a user