Fwd: operator precedence differs from C language

[Neo Liu <diabloneo at gmail dot com>]

---------- Forwarded message ----------
From: Neo Liu <diabloneo@gmail.com>
Date: Fri, Apr 2, 2010 at 9:49 AM
Subject: Re: operator precedence differs from C language
To: Josh Stone <jistone@redhat.com>


On Fri, Apr 2, 2010 at 1:15 AM, Josh Stone <jistone@redhat.com> wrote:
> On 04/01/2010 09:29 AM, Josh Stone wrote:
>> On 03/31/2010 07:36 PM, Neo Liu wrote:
>>> I found that the operator precedence of "&" and "==" differed from C
>>> language. Take a look at the following statements.
>>
>> That's not true -- in C and in stap, relational operators bind more
>> tightly than bitwise operators. Âhttp://tinyurl.com/9q6szp

I ran your test program and found that my problems due to my misunderstanding
of the C Language.

>
> You might also find this interesting:
> http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
>
> """
> Neonatal C
>
> Rapid changes continued after the language had been named, for example
> the introduction of the && and || operators. In BCPL and B, the
> evaluation of expressions depends on context: within if and other
> conditional statements that compare an expression's value with zero,
> these languages place a special interpretation on the and (&) and or (|)
> operators. In ordinary contexts, they operate bitwise, but in the B
> statement
>
> Â Âif (e1 & e2) ...
>
> the compiler must evaluate e1 and if it is non-zero, evaluate e2, and if
> it too is non-zero, elaborate the statement dependent on the if. The
> requirement descends recursively on & and | operators within e1 and e2.
> The short-circuit semantics of the Boolean operators in such
> `truth-value' context seemed desirable, but the overloading of the
> operators was difficult to explain and use. At the suggestion of Alan
> Snyder, I introduced the && and || operators to make the mechanism more
> explicit.
>
> Their tardy introduction explains an infelicity of C's precedence rules.
> In B one writes
>
> Â Âif (a==b & c) ...
>
> to check whether a equals b and c is non-zero; in such a conditional
> expression it is better that & have lower precedence than ==. In
> converting from B to C, one wants to replace & by && in such a
> statement; to make the conversion less painful, we decided to keep the
> precedence of the & operator the same relative to ==, and merely split
> the precedence of && slightly from &. Today, it seems that it would have
> been preferable to move the relative precedences of & and ==, and
> thereby simplify a common C idiom: to test a masked value against
> another value, one must write
>
> Â Âif ((a&mask) == b) ...
>
> where the inner parentheses are required but easily forgotten.
> """
>

Thank you for your elaboration.