However, the precedence of & vs &&, or & vs ||, etc is a source of problems.
& vs == is the real problem: `(val & MASK) == CONSTANT` needs parentheses due to this mistake.
`a & (b == c)` essentially almost never makes sense (== gives you a boolean, and when dealing with booleans you can use && instead), yet that it what you get by default if omitting the parentheses.
if ((a==0) && (b==0))
if (a==0 && b==0)Tangentially, I wonder if
if (a+b == 0)
Unless "equivalence" is supposed to be useful for comparing boolean expressions with unbound variables? But evaluating that would require a built-in SAT solver, to be remotely performant.
Also, just because two integers sum to 0 doesn't mean they're both equal to 0, so replacing (x == 0 && y == 0) with (x + y == 0) wouldn't be valid. Regardless, it wouldn't make for more performant code: compilers already translate (x == 0 && y == 0) into the assembly equivalent of ((x | y) == 0) automatically, without the programmer having to mess with their code.
Indeed, I forgot to specify unsigned.
Unless the integers were unsigned big-integers, in which case performing the long addition with carries would take Θ(n) time, as opposed to the simple Θ(1) operation of just checking both their bit-lengths.
Do you have any examples of this? In my experience you almost always want the bitwise operators to have a higher precedence than the logical operators, as using the result of logical operators as a bitmask makes little sense. Consider e.g. `A & B && C & D`, which currently is equivalent to `(A & B) && (C & D)`, but with reversed precedence would be equivalent to the almost nonsensical `A & (B && C) & D`.
Now, the precedence of == with respect to & and | is actually problematic (as Ritchie admits as well). Having `A == B | C` interpreted as `(A == B) | C` is almost never desirable. For extra annoyance, the shift operators do have higher precedence than comparison, so `A == B << C` does what you usually want (`A == (B << C)`).
arithmetic expressions?