Understanding the "memory-safe" dialect

Documentation
#1

I read the assembly docs 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:

function frac(UD60x18 x) pure returns (UD60x18 result) {
    assembly {
        result := mod(x, uUNIT)
    }
}

And:

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”)?
1 Like
#2

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.

2 Likes
#3

Thanks for your answer, Chris, all clear now!

This observation is so clarifying that it might be worth including in the documentation website!

Ditto for this!

1 Like