cerc-io/solidity
16
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #12876 from aathan/why-is-this-inline-assembly-not-memory-safe

Browse Source 
[Docs] clarify the reason for the memory-unsafe assembly example being unsafe
This commit is contained in:
Kamil Śliwak 2022-04-07 18:41:41 +02:00 committed by GitHub
commit e340cf6ca2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/assembly.rst
View File

@ -313,7 +313,8 @@ Furthermore, if the assembly block assigns to Solidity variables in memory, you
the Solidity variables only access these memory ranges. the Solidity variables only access these memory ranges.
Since this is mainly about the optimizer, these restrictions still need to be followed, even if the assembly block Since this is mainly about the optimizer, these restrictions still need to be followed, even if the assembly block
reverts or terminates. As an example, the following assembly snippet is not memory safe: reverts or terminates. As an example, the following assembly snippet is not memory safe, because the value of
``returndatasize()`` may exceed the 64 byte scratch space:
.. code-block:: solidity .. code-block:: solidity
@ -322,7 +323,8 @@ reverts or terminates. As an example, the following assembly snippet is not memo
revert(0, returndatasize()) revert(0, returndatasize())
} }
But the following is: On the other hand, the following code *is* memory safe, because memory beyond the location pointed to by the
free memory pointer can safely be used as temporary scratch space:
.. code-block:: solidity .. code-block:: solidity