3 ms·
> 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 lim
by tremon 2y ago
> 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 2y ago> 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.