Strict aliasing is an invariant that C compilers assume you as a developer will not violate, and use that assumption to make optimization choices that, if you as the developer have failed to follow the strict aliasing rules, could lead to undefined behavior. So it’s a variant that the compiler expects, but doesn’t enforce at compile time.
I guess it is possible to just disable all such optimizations to get a C compiler that doesn’t create UB just because strict aliasing rules were broken, but there are still many ways that you can trigger UB in C, while safe rust that compiles successfully theoretically has no UB at all.
Strict aliasing exists not for optimization, but for type alignment. You may need more space on stack to save uint32_t than uint8_t[5] because former has 32-bit alignment.
Either way, this is a rule that you as a human are required to follow, and if you fail the compiler is allowed to do anything, including killing your cat.
It’s not a rule that the compiler enforces by failing to build code with undefined behavior.
That is a fundamental, and extremely important, difference between C and rust.
Also, C compilers do make optimization decisions by assuming that you as a human programmer have followed these strict aliasing rules.
Has a few examples where code runs “properly” without optimizations but “improperly” with optimizations.
I put “improperly” in quotes because the C spec says that a compiler can do whatever it wants if you as a human invoke undefined behavior. Safe rust does not have undefined behavior, because if you write code which would invoke UB, rustc will refuse to build it.
You can’t, C have strict aliasing.
… Which compilers don’t consistently enforce, much like most undefined behavior in C.
How to enforce undefined behavior?
By refusing to compile any code that has undefined behavior. This is what rust’s compiler does, and is simply not possible for a C compiler to do.
To put it another way:
Strict aliasing is an invariant that C compilers assume you as a developer will not violate, and use that assumption to make optimization choices that, if you as the developer have failed to follow the strict aliasing rules, could lead to undefined behavior. So it’s a variant that the compiler expects, but doesn’t enforce at compile time.
I guess it is possible to just disable all such optimizations to get a C compiler that doesn’t create UB just because strict aliasing rules were broken, but there are still many ways that you can trigger UB in C, while safe rust that compiles successfully theoretically has no UB at all.
Strict aliasing exists not for optimization, but for type alignment. You may need more space on stack to save uint32_t than uint8_t[5] because former has 32-bit alignment.
Either way, this is a rule that you as a human are required to follow, and if you fail the compiler is allowed to do anything, including killing your cat.
It’s not a rule that the compiler enforces by failing to build code with undefined behavior.
That is a fundamental, and extremely important, difference between C and rust.
Also, C compilers do make optimization decisions by assuming that you as a human programmer have followed these strict aliasing rules.
https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8
Has a few examples where code runs “properly” without optimizations but “improperly” with optimizations.
I put “improperly” in quotes because the C spec says that a compiler can do whatever it wants if you as a human invoke undefined behavior. Safe rust does not have undefined behavior, because if you write code which would invoke UB, rustc will refuse to build it.
Compiler knows what is undefined behaviour better than all lemmy experts