Which operator(s) in C have wrong precedence?

  • A+

In the "Introduction" section of K&R C (2E), this paragraph is written:

C, like any other language, has its blemishes. Some of the operators have the wrong precedence; ...

Which operators are these? How are their precedence wrong?

Is this one of these cases?


There is a clear rule of precedence that is incontrovertible. The rule is so clear that for a strongly typed system (think Pascal) the wrong precedence would give clear unambiguous syntax errors at compile time. The problem with C is that since its type system is laissez faire the errors turn out to be more logical errors resulting in bugs rather than errors catch-able at compile time.

The Rule

Let ○ □ be two operators with type

○ : α × α → β
□ : β × β → γ
and α and γ are distinct types.


x ○ y □ z can only mean (x ○ y) □ z, with type assignment
x: α, y : α, z : β

whereas x ○ (y □ z) would be a type error because ○ can only take an α whereas the right sub-expression can only produce a γ which is not α

Now lets

Apply this to C

For the most part C gets it right

(==) : number × number → boolean
(&&) : boolean × boolean → boolean

so && should be below == and it is so


(+) : number × number → number
(==) : number × number → boolean

and so (+) must be above (==) which is once again correct

However in the case of bitwise operators

the &/| of two bit-patterns aka numbers produce a number ie
(&), (|) : number × number → number
(==) : number × number → boolean

And so a typical mask query eg. x & 0x777 == 0x777
can only make sense if (&) is treated as an arithmetic operator ie above (==)

C puts it below which in light of the above type rules is wrong

Of course Ive expressed the above in terms of math/type-inference

In more pragmatic C terms x & 0x777 == 0x777 naturally groups as x & (0x777 == 0x777) (in the absence of explicit parenthesis)

When can such a grouping have a legitimate use?
I (personally) dont believe there is any

IOW Dennis Ritchie's informal statement that these precedences are wrong can be given a more formal justification


:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: