* operator precedence differs from C language
@ 2010-04-01 2:37 Neo Liu
2010-04-01 16:29 ` Josh Stone
2010-04-01 16:30 ` Frank Ch. Eigler
0 siblings, 2 replies; 5+ messages in thread
From: Neo Liu @ 2010-04-01 2:37 UTC (permalink / raw)
To: SystemTap
I found that the operator precedence of "&" and "==" differed from C
language. Take a look at the following statements.
if ($flags & 07 == 0) { ... }
I thought this statement would first calculate ($flags & 07)
and then calculate (($flags & 07) == 0), but the it is not the case.
It first calculates (07 == 0) and then ($flags & (07 == 0)),
so the result is 0 but not the expected 1. As a solution, I wrote the
statement as:
if (($flags & 07) == 0) { ... }
to get the computing order I want
Is this the stap language feature, or should I report this as a bug?
Thanks!
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: operator precedence differs from C language
2010-04-01 2:37 operator precedence differs from C language Neo Liu
@ 2010-04-01 16:29 ` Josh Stone
2010-04-01 17:15 ` Josh Stone
2010-04-01 16:30 ` Frank Ch. Eigler
1 sibling, 1 reply; 5+ messages in thread
From: Josh Stone @ 2010-04-01 16:29 UTC (permalink / raw)
To: Neo Liu; +Cc: SystemTap
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
Here's a program to convince yourself of this:
#include <stdio.h>
#define TEST(e) printf("( %s ) = %d\n", #e, e)
int main(int argc, const char *argv[])
{
if (argc < 2) return 1;
int x = atoi(argv[1]);
TEST(x);
TEST(x & 07);
TEST((x & 07) == 0);
TEST(x & (07 == 0));
TEST(x & 07 == 0);
return 0;
}
Josh
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: operator precedence differs from C language
2010-04-01 2:37 operator precedence differs from C language Neo Liu
2010-04-01 16:29 ` Josh Stone
@ 2010-04-01 16:30 ` Frank Ch. Eigler
1 sibling, 0 replies; 5+ messages in thread
From: Frank Ch. Eigler @ 2010-04-01 16:30 UTC (permalink / raw)
To: Neo Liu; +Cc: SystemTap
Neo Liu <diabloneo@gmail.com> writes:
> I found that the operator precedence of "&" and "==" differed from C
> language. Take a look at the following statements.
> if ($flags & 07 == 0) { ... }
Actually, I think we do it the same way C does. Comparison operators
such as "==" have higher precedence.
% cat foo.c
int main () {
printf("%d\n", 0xf0 & 0xff == 0);
}
% cat foo.stp
probe begin {printf("%d\n", 0xf0 & 0xff == 0); exit()}
Both these print 0 for == or !=.
- FChE
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: operator precedence differs from C language
2010-04-01 16:29 ` Josh Stone
@ 2010-04-01 17:15 ` Josh Stone
[not found] ` <u2n861674c01004011849o94f1a327za4bc14aff28e3d9@mail.gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Josh Stone @ 2010-04-01 17:15 UTC (permalink / raw)
To: Neo Liu; +Cc: SystemTap
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
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.
"""
^ permalink raw reply [flat|nested] 5+ messages in thread
* Fwd: operator precedence differs from C language
[not found] ` <u2n861674c01004011849o94f1a327za4bc14aff28e3d9@mail.gmail.com>
@ 2010-04-02 2:00 ` Neo Liu
0 siblings, 0 replies; 5+ messages in thread
From: Neo Liu @ 2010-04-02 2:00 UTC (permalink / raw)
To: SystemTap
---------- 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-04-02 2:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-01 2:37 operator precedence differs from C language Neo Liu
2010-04-01 16:29 ` Josh Stone
2010-04-01 17:15 ` Josh Stone
[not found] ` <u2n861674c01004011849o94f1a327za4bc14aff28e3d9@mail.gmail.com>
2010-04-02 2:00 ` Fwd: " Neo Liu
2010-04-01 16:30 ` Frank Ch. Eigler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).