48

In the C programing language, why do the bitwise operators (& and |) have lower precedence than the equality operator (==)? It does not make sense to me.

jww
  • 97,681
  • 90
  • 411
  • 885
poida
  • 3,403
  • 26
  • 26

3 Answers3

54

You need to ask Brian Kernighan or Dennis Ritchie.
From this forum: http://bytes.com/topic/c/answers/167377-operator-precedence

The && and || operators were added later for their "short-circuiting" behavior. Dennis Ritchie admits in retrospect that the precedence of the bitwise operators should have been changed when the logical operators were added. But with several hundred kilobytes of C source code in existence at that point and an installed base of three computers, Dennis thought it would be too big of a change in the C language...

So, that might be a reason? I'm guessing since there are several layers of bitwise precendence (unlike relational comparisons) that it's cruft that's existed since...forever...and just was never corrected.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
Caladain
  • 4,801
  • 22
  • 24
  • 5
    That quote is actually misquoted. Dennis Ritchie explains this himself in his paper "Chistory", which [you can read here](http://cm.bell-labs.co/who/dmr/chist.html). In my opinion, Ritchie's wording is much better. Ritchie regretted having the precedence as such, but it was made so to have minimal conversion friction from the B language, C's predecessor, when he was first forming the C language. B only supported `&` on cells and didn't have an explicit boolean operator due to B's lack of a type system. This also explains why "true" means "not 0" -- bitwise AND doesn't always yield a perfect 1. – Qix - MONICA WAS MISTREATED Sep 26 '16 at 21:38
  • But `==` isn't a short-circuiting operator so why does this answer the question? However, thank you @Qix, because your comment also explains why the bitwise operators all have different (seemingly arbitrary) precedences - they're from B as seen in the _[B Tutorial Appendix D](https://www.bell-labs.com/usr/dmr/www/btut.html)_ (a question which had been vexing me). (And my guess is that B did it that way for no other reason than that it is easy to write a recursive descent parser with that kind of expression grammar.) – davidbak Sep 10 '17 at 18:10
18

It doesn't make sense to Dennis Ritchie, either, in retrospect.

http://www.lysator.liu.se/c/dmr-on-or.html

&& and || were added to the language after | and &, and precedence was maintained for reasons of compatibility.

Michael Cornelius
  • 1,516
  • 1
  • 11
  • 11
5

I don't have an authoritative answer as to why K&R chose the precedence they did. One example that makes a fair amount of sense would be this one:

if (x == 1 & y == 0) {
    /* ... */
}

Since this is the bitwise AND operator it uses a non-short-circuiting evaluation mode, as would

if (x == 1 | y == 0) {
    /* ... */
}

use the non-short-circuiting OR operator. This is probably why they chose to have the precedence group this way, but I agree with you that in retrospect it doesn't seem like a good idea.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
  • 3
    This doesn't make any sense. Why would you use the bitwise operator instead of a logical one in this case? – Nathan Fellman Jan 13 '11 at 20:55
  • 3
    @Nathan Fellman- Caladain's answer seems to hit this one on the head. – templatetypedef Jan 13 '11 at 20:59
  • 2
    Right. The precedence of `&` and `|` makes perfect sense as logical operators, but little sense as bitwise operators. – dan04 Jan 15 '11 at 17:57
  • Kudos for this awesome non-short-circuiting logical operators usage. Never thought of that. – Spidey Apr 12 '12 at 18:25
  • @NathanFellman If you really need both `aaaa()` and `bbbb()` to run and you like unreadable code, you'd write `if (aaaa() == 1 & bbbb() == 0)`. There really is no other reason. –  Sep 05 '16 at 22:38