• @Jordan_U@lemmy.ml
    link
    fedilink
    110 months ago

    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.

    • @uis@lemmy.world
      link
      fedilink
      110 months ago

      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.

      • @Jordan_U@lemmy.ml
        link
        fedilink
        110 months ago

        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.