From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11657 invoked by alias); 2 Apr 2010 02:00:01 -0000 Received: (qmail 11551 invoked by uid 22791); 2 Apr 2010 02:00:00 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SARE_MSGID_LONG45 X-Spam-Check-By: sourceware.org Received: from mail-pz0-f202.google.com (HELO mail-pz0-f202.google.com) (209.85.222.202) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Apr 2010 01:59:55 +0000 Received: by pzk40 with SMTP id 40so1268774pzk.23 for ; Thu, 01 Apr 2010 18:59:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.221.1 with HTTP; Thu, 1 Apr 2010 18:59:53 -0700 (PDT) In-Reply-To: References: <4BB4C9DC.4040305@redhat.com> <4BB4D49D.4010102@redhat.com> Date: Fri, 02 Apr 2010 02:00:00 -0000 Received: by 10.142.3.41 with SMTP id 41mr616572wfc.291.1270173593592; Thu, 01 Apr 2010 18:59:53 -0700 (PDT) Message-ID: Subject: Fwd: operator precedence differs from C language From: Neo Liu To: SystemTap Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q2/txt/msg00009.txt.bz2 ---------- Forwarded message ---------- From: Neo Liu Date: Fri, Apr 2, 2010 at 9:49 AM Subject: Re: operator precedence differs from C language To: Josh Stone On Fri, Apr 2, 2010 at 1:15 AM, Josh Stone 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 "=3D=3D" 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. =C2=A0http://tinyurl.com/9q6szp I ran your test program and found that my problems due to my misunderstandi= ng 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 > > =C2=A0 =C2=A0if (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 > > =C2=A0 =C2=A0if (a=3D=3Db & 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 =3D=3D. 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 =3D=3D, and merely split > the precedence of && slightly from &. Today, it seems that it would have > been preferable to move the relative precedences of & and =3D=3D, and > thereby simplify a common C idiom: to test a masked value against > another value, one must write > > =C2=A0 =C2=A0if ((a&mask) =3D=3D b) ... > > where the inner parentheses are required but easily forgotten. > """ > Thank you for your elaboration.