Operator presidence problem. Bug?

Hello everyone! I was just mucking around one of my scripts, trying to find the reason behind some strange behavior. It turns out, the addition of a set of parentheses around an operation squashed my bug.

The problem, is that I'm unsure why the parenthesis were needed. I was performing a conditional statement where I checked if a bit was set in a bitfield.

Here's what the statement looked like:
(bitfield & bit == bit);

Oddly enough, that returned a non-zero value almost constantly. So, I added parenthesis around it, like so:
((bitfield & bit) == bit);

This fixed the problem, but I still dont understand why == has presidence over &.

I had the minset that the bitwise comparison operators had precidence over the boolean comparison operators, since the bitwise operators were used more for things like assignment. I sort of had them in the same catagory as arithmatic operators (+, -, /, *).

My rationalization for stating that this was a possible precidence bug, was the question: dont you expect (1 + 2 == 3) to be equivelant to ((1 + 2) == 3)?

So is it a bug? I dont have extensive experiance with languages other then LSL, so I dont know alot here
==Chris

PS: Im not looking for a lecture on the usage of parthenesis. I *know* that they're good for readability, I was just lazy when I coded this small section.

Ever since Kernighan and Ritchie (197 C like languges have had equality lower in precedence then the arithmetic operators and higher than bitwise operators.

Which actually caught me by surprise because I never would have expected that (1 + 2 == 3) is parsed as ((1 + 2) == 3) without looking it up.

A Table of Precedence for LSL would be good. If it follows the usual rules then I'll pasts a table from the book i'm reading "C++ How to Program" Which is a great book by the way for a beginner like me.
Unless someone else puts in a table of precedence first, I'll do it when I get home. Might be useful to some.

Here is the most non-blinky non-authoritative reference I could quickly find.

Please note that although the Linden LSL manual does not specifically address precedence, it does seem to be ordered according to descending precedence. Also, LSL has operators for intrinsic types that C doesn't, and although the assignment-ops (+=, *=, etc.) aren't formally supported by LSL they do compile a;though their behavior is (possibly) undefined.

I should also mention Jake's fine Jake's fine LSL windows help file and the community's LSL Wiki both of which augment the LSL documentation but don't explicitly address operator precedence.