Hi Chris,

I follow your blog and read your last post where libmemory is
linked, and also read your recent post about inline asm. Following
your rule 2:

"(2) It should nearly always be volatile"

I was surprised to see that volatile is not used in the memmove
implementation:
asm ("std");
I assume it is intentional but a code comment explaining why would
be great given your advice (which I agree with):

"This prevents compilers from eliding or re-ordering the assembly.
As a special rule, inline assembly lacking output constraints is
implicitly volatile. Despite this, please use volatile anyway! When
I do not see volatile it’s likely a defect. Stopping to consider if
it’s this special case slows understanding and impedes code review."

Thanks,
Benjamin

Thanks for reaching out, Benjamin. Sharp of you to notice that!

Note that my article says its "focus is entirely extended assembly, and 
not basic assembly." That std asm is a basic assembly block and so "has 
different rules." No constraints means no special case to consider. Review 
is more basic, "Will this blunt tool behave appropriately here?" instead 
of subtler issues with constraints and volatile. Note how the top-level 
basic asm blocks in the tests are also not explicitly volatile.