# Understanding the "memory-safe" dialect **URL:** \ **Category:** Documentation\ **Created:** [February 5, 2023, 6:17pm UTC](https://forum.soliditylang.org/t/understanding-the-memory-safe-dialect/1481 "2023-02-05T18:17:34Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![paulrberg](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/paulrberg/32/537_2.png) [@paulrberg](https://forum.soliditylang.org/u/paulrberg)\ **Post date:** [February 5, 2023, 6:17pm UTC](https://forum.soliditylang.org/t/understanding-the-memory-safe-dialect/1481/1 "2023-02-05T18:17:34Z")
I read the [assembly docs](https://docs.soliditylang.org/en/v0.8.18/assembly.html) but I am still a bit unsure regarding when I should apply the `("memory-safe")` dialect, and when not. For instance, take the following examples taken from [PRBMath](https://github.com/PaulRBerg/prb-math/blob/c7f76a7179afecefc0df3819e9bc4d2f8a20230c/src/Common.sol#L71-L75): ```solidity function frac(UD60x18 x) pure returns (UD60x18 result) { assembly { result := mod(x, uUNIT) } } ``` And: ```solidity function msb(uint256 x) pure returns (uint256 result) { // 2^128 assembly { let factor := shl(7, gt(x, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)) x := shr(factor, x) result := or(result, factor) } // ... } ``` The docs say this: > Inline assembly that neither involves any operations that access memory nor assigns to any Solidity variables in memory is automatically considered memory-safe and does not need to be annotated. The first example simply reads a variable from the stack and a const, so my instinct would say there is no need for the dialect because the code is memory safe by default. But the second example assigns to `result`, which is part of returndata, so here I am not so sure. My questions are: 1. Do the examples above count as code snippets that do _not_ involve any operations that access memory? 2. Does it hurt if I add the `("memory-safe")` dialect to a code snippet that doesn’t actually need it (e.g. a code that “neither involves any operations that access memory nor assigns to any Solidity variables in memory”)? ---
**Author:** ![chriseth](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/chriseth/32/24_2.png) [@chriseth](https://forum.soliditylang.org/u/chriseth)\ **Post date:** [February 6, 2023, 11:05am UTC](https://forum.soliditylang.org/t/understanding-the-memory-safe-dialect/1481/2 "2023-02-06T11:05:19Z")
A return variable is just like any other local variable, so in your case, it is a stack variable that you can assign in the inline assembly block and it is still memory-safe. Both your inline assembly blocks do not need an annotation and are still considered memory-safe by the compiler. Adding it does not hurt, though. In general, the only inline assembly statements that require “memory-safe” (and also could be memory-unsafe!) are opcodes that concern memory (mload, mstore, calldatacopy, call, msize, …) or access to local variables outside of the inline assembly block that are of memory reference type. Code that only touches storage or storage reference type is fine as well, as is calldata. ---
**Author:** ![paulrberg](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/paulrberg/32/537_2.png) [@paulrberg](https://forum.soliditylang.org/u/paulrberg)\ **Post date:** [February 6, 2023, 12:13pm UTC](https://forum.soliditylang.org/t/understanding-the-memory-safe-dialect/1481/3 "2023-02-06T12:13:55Z")
Thanks for your answer, Chris, all clear now! > [@chriseth](#): > > the only inline assembly statements that require “memory-safe” (and also could be memory-unsafe!) are opcodes that concern memory (mload, mstore, calldatacopy, call, msize, …) This observation is so clarifying that it might be worth including in the documentation website! > [@chriseth](#): > > Code that only touches storage or storage reference type is fine as well, as is calldata Ditto for this! ---
**Author:** ![Surya-Prasath](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/surya-prasath/32/975_2.png) [@Surya-Prasath](https://forum.soliditylang.org/u/Surya-Prasath)\ **Post date:** [June 15, 2023, 8:44pm UTC](https://forum.soliditylang.org/t/understanding-the-memory-safe-dialect/1481/4 "2023-06-15T20:44:32Z")
Does using Memory-safe dialect in assembly actually has any effects on the memory. Can we find any difference with and without the dialect in memory? ---
**Author:** ![Worthy](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/worthy/32/1034_2.png) [@Worthy](https://forum.soliditylang.org/u/Worthy)\ **Post date:** [July 19, 2023, 2:33am UTC](https://forum.soliditylang.org/t/understanding-the-memory-safe-dialect/1481/5 "2023-07-19T02:33:26Z")
Using the memory-safe dialect in assembly does have effects on memory safety in Solidity contracts, but it does not directly affect the underlying memory in terms of performance or storage. The memory-safe dialect primarily affects how you write and handle assembly code in Solidity, providing additional safety features and restrictions to prevent common programming errors. ---
**Author:** ![cameel](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/cameel/32/34_2.png) [@cameel](https://forum.soliditylang.org/u/cameel)\ **Post date:** [July 19, 2023, 4:59pm UTC](https://forum.soliditylang.org/t/understanding-the-memory-safe-dialect/1481/6 "2023-07-19T16:59:04Z")
This is completely wrong. Using memory-safe assembly does not enable any safety checks or restrictions. Quite the opposite. The compiler cannot determine on its own whether the code is memory-safe or not. By using this feature, you’re declaring that it is and signaling that the compiler can do things that would not be safe to do otherwise. If it turns out it’s not memory-safe, bad things can happen.