[tremon]

> C does actually have aliasing rules

If you're referring to e.g. gcc's -f[no-]strict-aliasing option, then that's more about type compatibility than about limiting the scope of memory aliasing in general. If you mean something else, I'm interested to hear more.

> this is the list for D, not in general

Yes, I know. But it's the first authoritative source I could think of on memory safety in C-like languages. I don't think the list is wrong for C proper, just probably not exhaustive.

> Rust is fine with you taking the address of a local variable

Yes! But circling back to the earlier point: in Rust you can do this specifically because the language has well-defined lifetime semantics on variables and ownership. And as such, Rust can guarantee that a) a pointer to a memory location does not outlive the scope of the memory allocation itself, and b) when two variables/pointers refer to the same memory location, there is a compiler-enforced protocol for accessing and mutating that memory.

[steveklabnik]

> then that's more about type compatilibity than about limiting the scope of memory aliasing in general.

It's about limiting the ability of pointers to alias. The C standard even has this parenthetical:

> The intent of this list is to specify those circumstances in which an object can or cannot be aliased.

You are correct that it's a pretty narrow set of rules. There are only six items on that list. But it's still an aliasing rule.