4 ms·

I read the article as a criticism of the strict aliasing rules in C. I think that you're attributing something to the author that they couldn't possibly believe

I read the article as a criticism of the strict aliasing rules in C. I think that you're attributing something to the author that they couldn't possibly believe.

sanxiyn 6y ago
This is not a strict aliasing rule. I actually agree strict aliasing optimizations are mostly useless. (Exhibit: Rust has no strict aliasing.)
- aw1621107 6y ago
  > Exhibit: Rust has no strict aliasing. Isn't that arguably because Rust has even stricter aliasing rules? Not only are you not allowed to have differently-typed mutable references to the same memory, you (approximately) aren't allowed to have multiple mutable references to the same memory, period, even if they are the same type.
  - sanxiyn 6y ago
    Yes, but for most optimizations (including jcranmer's example), just "aliasing rule" is sufficient, not C's "strict aliasing rule". The gist is that pointers shouldn't be able to do out-of-bound accesses. The additional restriction that pointers should be well typed is mostly unnecessary, both in C and in Rust. Note that pointers-are-integers directly imply no restrictions whatsoever on out-of-bound accesses.
    - sanxiyn 6y ago
      To elaborate, the rule is roughly that if a and b are different arrays, a[i] and b[j] do not alias. If pointers-are-integers, a[b-a] and b[0] alias. In C standard, while a[b-a] and b[0] are same integers, they are not same pointers, because "a and b are different arrays" imply a[b-a] is out-of-bound access hence invalid. This is actually very reasonable. Pointers are not integers.
      - aw1621107 6y ago
        > the rule is roughly that if a and b are different arrays, a[i] and b[j] do not alias. This is technically stricter than the strict aliasing rule, isn't it? Since it also disallows aliasing through pointers of the same type? Or am I getting concepts mixed up here, since strict aliasing is for pointers and you're talking about arrays?

I read the article as a criticism of the strict aliasing rules in C. I think that you're attributing something to the author that they couldn't possibly believe.

sanxiyn 6y ago

This is not a strict aliasing rule. I actually agree strict aliasing optimizations are mostly useless. (Exhibit: Rust has no strict aliasing.)

aw1621107 6y ago
> Exhibit: Rust has no strict aliasing. Isn't that arguably because Rust has even stricter aliasing rules? Not only are you not allowed to have differently-typed mutable references to the same memory, you (approximately) aren't allowed to have multiple mutable references to the same memory, period, even if they are the same type.
- sanxiyn 6y ago
  Yes, but for most optimizations (including jcranmer's example), just "aliasing rule" is sufficient, not C's "strict aliasing rule". The gist is that pointers shouldn't be able to do out-of-bound accesses. The additional restriction that pointers should be well typed is mostly unnecessary, both in C and in Rust. Note that pointers-are-integers directly imply no restrictions whatsoever on out-of-bound accesses.
  - sanxiyn 6y ago
    To elaborate, the rule is roughly that if a and b are different arrays, a[i] and b[j] do not alias. If pointers-are-integers, a[b-a] and b[0] alias. In C standard, while a[b-a] and b[0] are same integers, they are not same pointers, because "a and b are different arrays" imply a[b-a] is out-of-bound access hence invalid. This is actually very reasonable. Pointers are not integers.
    - aw1621107 6y ago
      > the rule is roughly that if a and b are different arrays, a[i] and b[j] do not alias. This is technically stricter than the strict aliasing rule, isn't it? Since it also disallows aliasing through pointers of the same type? Or am I getting concepts mixed up here, since strict aliasing is for pointers and you're talking about arrays?