&& and || Operator precedence enforcement

[Richard Bos]

as ++j and ++k would first be evaluated and && operator applied to
obtain the result to be TRUE (3 && 1). Hence, ++i wouldn't be evaluated
as one part of || goes TRUE.

The ANSI C specification clearly states that && has precedence over ||.

The ISO C specification states no such thing, since "precedence" is
ambiguous.
What it _does_ state is this:
* To begin with, all logical operators are evaluated left-to-right, with
short-circuit evaluation. This means that it's possible to do this:

if (ptr!=NULL && *ptr!='A') ...

and be certain that your pointer is tested before being dereferenced.
* The logical and (&&) operator binds more closely than the logical or
(||). That is, x || y && z means x || (y && z), not (x || y) && z. The
order of evaluation remains the same, however.

Richard

 

[Vivek N]

Hi Folks,
This question may well have been asked and answered before. But, sorry
that I couldn't find one from the archives.

I typed up this program and compiled it with gcc 3.3.2
main() {
int i = -3,j= 2,k=0,m;

m = ++i || ++j && ++k;
printf("\n%d %d %d %d\n",i,j,k,m);
}
and got the output to be
-2 2 0 1

I presumed that the answer should have well been
-3 3 1 1

as ++j and ++k would first be evaluated and && operator applied to
obtain the result to be TRUE (3 && 1). Hence, ++i wouldn't be evaluated
as one part of || goes TRUE.

The ANSI C specification clearly states that && has precedence over ||.

Could someone explain why this strange "-2 2 0 1" output for the program
is obtained?

Cheers
Vivek

 

[pete]

Hi Folks,
This question may well have been asked and answered before. But, sorry
that I couldn't find one from the archives.

I typed up this program and compiled it with gcc 3.3.2
main() {
int i = -3,j= 2,k=0,m;

m = ++i || ++j && ++k;
printf("\n%d %d %d %d\n",i,j,k,m);
}
and got the output to be
-2 2 0 1

I presumed that the answer should have well been
-3 3 1 1

as ++j and ++k would first be evaluated and && operator applied to
obtain the result to be TRUE (3 && 1).
Hence, ++i wouldn't be evaluated
as one part of || goes TRUE.

The ANSI C specification clearly states that &&
has precedence over ||.

(a || b && c), is the same as (a || (b && c)).

Could someone explain why this strange "-2 2 0 1"
output for the program is obtained?

j and k are not evaluated at all.

The left operand of || is evaluted before the right.
The right operand of || is evaluated conditionally only if
the left operand is equal to zero.
Your left operand (++i), is not equal to zero.
Your right operand (++j && ++k) is not evaluated.

 

[Christopher Benson-Manica]

main() {

Allowing the return type of a function to default to int is illegal in
C99 and dubious otherwise.

int i = -3,j= 2,k=0,m;

m = ++i || ++j && ++k;
printf("\n%d %d %d %d\n",i,j,k,m);

Could someone explain why this strange "-2 2 0 1" output for the program
is obtained?

Not strange at all, thanks to short-circuit evaluation. The fact that
&& has precedence over || only means that the assignment to m is
equivalent to

m=++i || (++j && ++k);

++i is computed first, and if it is nonzero (true), then the entire
statement is guaranteed to be true regardless of what (++j && ++k) is.
In C, this means that (++j && ++k) will not be evaluated. That is
what short-circuit evaluation is, and that is why only i is
incremented in the code you posted.

 

[Grumble]

Richard Bos wrote:

<snip>

Richard,

I think your clock is incorrectly set.

The original message is dated 14:34:18 GMT (1) and your reply is dated
13:56:05 GMT (2).

(1) Date: 19 Jan 2004 06:34:18 -0800
(2) Date: Mon, 19 Jan 2004 13:56:05 GMT

 

[Richard Bos]

Richard Bos wrote:

I think your clock is incorrectly set.

This is true (I've been looking for a gizmo that keeps it set to an
atomic clock, but I'm not paying $39.95 to some vague shareware firm for
it, so in the mean time I'm correcting it by hand every now and then)...

The original message is dated 14:34:18 GMT (1) and your reply is dated
13:56:05 GMT (2).

....but this doesn't necessarily indicate that. Usenet is weird.

Richard

 

[Dan Pop]

Richard,

I think your clock is incorrectly set.

The original message is dated 14:34:18 GMT (1) and your reply is dated
13:56:05 GMT (2).

(1) Date: 19 Jan 2004 06:34:18 -0800
(2) Date: Mon, 19 Jan 2004 13:56:05 GMT

How did you decide that the original message was correctly time stamped?

Dan

 

[Sean Kenwrick]

Hi Folks,
This question may well have been asked and answered before. But, sorry
that I couldn't find one from the archives.

I typed up this program and compiled it with gcc 3.3.2
main() {
int i = -3,j= 2,k=0,m;

m = ++i || ++j && ++k;
printf("\n%d %d %d %d\n",i,j,k,m);
}
and got the output to be
-2 2 0 1

I presumed that the answer should have well been
-3 3 1 1

as ++j and ++k would first be evaluated and && operator applied to
obtain the result to be TRUE (3 && 1). Hence, ++i wouldn't be evaluated
as one part of || goes TRUE.

The ANSI C specification clearly states that && has precedence over ||.

The precedence of an operator only defines where brackets are implicitely
placed to avoid abiguity. Thus a || b && c evaluates to a || (b && c)
rather than (a || b) && c. But after that the conditional statement is
executed left to right and will abort as soon as it is know that the
condition is false, which is why the ++j and ++k are not evaluated. I've
seen some compilers with an option to force all expressions in a conditional
statement to be evaluated so check your compiler if you really need this ..

Sean

 

[Nudge]

How did you decide that the original message was correctly time stamped?

The original message showed up on my system when I downloaded new
messages at approximately 14:40:00 GMT.

Then Pete's and Christopher's messages showed up on my system when I
downloaded new messages at approximately 14:55:00 GMT.

When Richard's message showed up 5 minutes later, I figured it was
more probable that the first 3 were correctly time-stamped, and it
was Richard's clock which was incorrectly set.

Are you satisfied with my answer?

 

[Jarno A Wuolijoki]

m = ++i || ++j && ++k;

as ++j and ++k would first be evaluated and && operator applied to
obtain the result to be TRUE (3 && 1). Hence, ++i wouldn't be evaluated
as one part of || goes TRUE.
The ANSI C specification clearly states that && has precedence over ||.

Your reasoning doesn't make sense as ++ has even higher precedence than &&.

 

[Peter Nilsson]

The ISO C specification states no such thing, since "precedence" is
ambiguous.

How so?

...
* The logical and (&&) operator binds more closely than the logical or
(||). That is, x || y && z means x || (y && z), not (x || y) && z.

6.5p3: The grouping of operators and operands is indicated by the syntax.(71

71) The syntax specifies the precedence of operators in the evaluation of an
expression, ...

6.5.13:
logical-AND-expression:
inclusive-OR-expression
logical-AND-expression && inclusive-OR-expression

What's the difference between 'binds' and precedence?

 

[Nudge]

The precedence of an operator only defines where brackets are
implicitely placed to avoid abiguity. Thus a || b && c evaluates
to a || (b && c) rather than (a || b) && c. But after that the
conditional statement is executed left to right and will abort as
soon as it is known that the condition is false, which is why the
++j and ++k are not evaluated. I've seen some compilers with an
option to force all expressions in a conditional statement to be
evaluated so check your compiler if you really need this ..

If one wanted to force all expressions in a conditional statement to
be evaluated, instead of

a || b && c

I believe one could write

(a != 0) | (b != 0) & (c != 0)

 

[Nudge]

The precedence of an operator only defines where brackets are
implicitely placed to avoid abiguity. Thus a || b && c evaluates
to a || (b && c) rather than (a || b) && c. But after that the
conditional statement is executed left to right and will abort as
soon as it is known that the condition is false, which is why the
++j and ++k are not evaluated. I've seen some compilers with an
option to force all expressions in a conditional statement to be
evaluated so check your compiler if you really need this ..

If one wanted to force all expressions in a conditional statement to
be evaluated, instead of

a || b && c

I believe one could write

(a != 0) | (b != 0) & (c != 0)

 

[Brett Frankenberger]

a = 1
b = 0
c = 0

((a != 0) | (b != 0) & (c != 0)) = 0
((a != 0) | ((b != 0) & (c != 0))) = 1

Nope. Those are both 1.

-- Brett

 

[pete]

Nope. Those are both 1.

Thank you.

 

[Vivek N]

Your reasoning doesn't make sense as ++ has even higher precedence than &&.

Folks, Thanks for all your inputs. The following statement by Sean in
this thread, throws some better light for me on this issue:

"The precedence of an operator only defines where brackets are
implicitely
placed to avoid abiguity. Thus a || b && c evaluates to a || (b && c)
rather than (a || b) && c. But after that the conditional statement
is
executed left to right and will abort as soon as it is know that the
condition is false, which is why the ++j and ++k are not evaluated.
I've
seen some compilers with an option to force all expressions in a
conditional
statement to be evaluated so check your compiler if you really need
this .."

Thanks Sean, and all others.

 

[Christian Bau]

a = 1
b = 0
c = 0

((a != 0) | (b != 0) & (c != 0)) = 0
((a != 0) | ((b != 0) & (c != 0))) = 1

That would be quite surprising, unless the C Standard has changed the
precedence of & and | and nobody told me.

 

[Richard Bos]

How so?

It is generally assumed by newbies to imply both order of evaluation
_and_ closeness of binding, as demonstrated by the OP.

Richard

 

[Dan Pop]

The original message showed up on my system when I downloaded new
messages at approximately 14:40:00 GMT.

Then Pete's and Christopher's messages showed up on my system when I
downloaded new messages at approximately 14:55:00 GMT.

When Richard's message showed up 5 minutes later, I figured it was
more probable that the first 3 were correctly time-stamped, and it
was Richard's clock which was incorrectly set.

Are you satisfied with my answer?

Looks like a perfect non-sequitur to me. There is no connection between
the order Usenet messages arrive at one site and the order in which they
were posted. So, it is perfectly possible that the original message was
incorrectly time stamped and that Richard was the first person to post a
reply to it, even if you got other replies before his. No need to assume
that the other messages were incorrectly time stamped in order to validate
this scenario.

Dan