Why does it suggest parentheses for the code snippet?

[lovecreatesbea...]

Isn't code at line 2 correct?

a.c:2: warning: suggest parentheses around && within ||

int isleap(int year){
if (year % 4 == 0 && year % 100 != 0 || year % 400 == 0) /*line
2*/
return 1;
return 0;
}

 

[Ben Pfaff]

Isn't code at line 2 correct?

a.c:2: warning: suggest parentheses around && within ||

int isleap(int year){
if (year % 4 == 0 && year % 100 != 0 || year % 400 == 0) /*line
2*/
return 1;
return 0;
}

No. This is in the FAQ.

20.32: Will 2000 be a leap year? Is (year % 4 == 0) an accurate test
for leap years?

A: Yes and no, respectively. The full expression for the present
Gregorian calendar is

year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)

See a good astronomical almanac or other reference for details.
(To forestall an eternal debate: references which claim the
existence of a 4000-year rule are wrong.) See also questions
13.14 and 13.14b.

 

[mark_bluemel]

Isn't code at line 2 correct?

Yeah. It's correct, but it's not ugly.

a.c:2: warning: suggest parentheses around && within ||

Your compiler has good taste Which one is it?

int isleap(int year){
if (year % 4 == 0 && year % 100 != 0 || year % 400 == 0) /*line
2*/
return 1;
return 0;

}

Bonus points for "return(!(year % 4) && (year % 100) || !(year %
400));" surely?

 

[Walter Roberson]

Isn't code at line 2 correct?

a.c:2: warning: suggest parentheses around && within ||

int isleap(int year){
if (year % 4 == 0 && year % 100 != 0 || year % 400 == 0) /*line
2*/
return 1;
return 0;
}

&& binds more tightly than ||, so the test is equivilent to

(((year % 4 == 0) && (year % 100 != 0)) || (year % 400 == 0))

However, it is relatively common for people to mistakenly think of
&& and || as having the same precedences, and so it is common
for people to read the operators from left to right. It doesn't
make a difference in this particular case, but if you had written,

if (year % 400 == 0 || year % 4 == 0 && year % 100 != 0)

then people would tend to (mistakenly) read this as

if ((year % 400 == 0 || year % 4 == 0) && year % 100 != 0)

when really it is

if (year % 400 == 0 || (year % 4 == 0 && year % 100 != 0))

The warning is altering you to the possibility of the common misreading.

 

[christian.bau]

No. This is in the FAQ.

20.32: Will 2000 be a leap year? Is (year % 4 == 0) an accurate test
for leap years?

A: Yes and no, respectively. The full expression for the present
Gregorian calendar is

year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)

The expressions are different, but always produce the same result.

 

[Ben Pfaff]

The expressions are different, but always produce the same result.

For the record, that's why I canceled my article quoted above
soon after posting it.

 

[Old Wolf]

Bonus points for "return(!(year % 4) && (year % 100) || !(year %
400));" surely?

Not really: your code would still trigger the warning in the OP,
and you have superfluous brackets around the expression being
returned.

 

[lovecreatesbea...]

No. This is in the FAQ.
year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)

The code in my last post is from K&R2, isn't K&R right?

 

[Richard Heathfield]

Ben Pfaff said:

For the record, that's why I canceled my article quoted above
soon after posting it.

"Anyone who thinks programming dates is easy to get right the first time
probably hasn't done much of it." - Peter van der Linden

 

[David Wade]

Isn't code at line 2 correct?

Its not obvious from a first glance if it is or is not correct. Whilst the
precedance of arithmetic operators is easily remembered, when you mix
arithmetic and comparative operators the order of evaluation is not clear.
Inserting parenthesis makes this clear.

 

[David Wade]

&& binds more tightly than ||, so the test is equivilent to

(((year % 4 == 0) && (year % 100 != 0)) || (year % 400 == 0))

However, it is relatively common for people to mistakenly think of
&& and || as having the same precedences, and so it is common
for people to read the operators from left to right. It doesn't
make a difference in this particular case, but if you had written,

if (year % 400 == 0 || year % 4 == 0 && year % 100 != 0)

then people would tend to (mistakenly) read this as

if ((year % 400 == 0 || year % 4 == 0) && year % 100 != 0)

when really it is

if (year % 400 == 0 || (year % 4 == 0 && year % 100 != 0))

The warning is altering you to the possibility of the common misreading.

Along the same lines GCC suggests parenthesis around constructs of the form

if( x=mysub(a,b,c) ) {

Any thoughts on why? It seems obvious to me that this is assigning the
return from mysub to x and then testing it...

 

[Mark L Pappin]

Along the same lines GCC suggests parenthesis around constructs of the form

if( x=mysub(a,b,c) ) {

Any thoughts on why? It seems obvious to me that this is assigning the
return from mysub to x and then testing it...

For the same reason: while it's valid code, it differs from
if( x==mysub(a,b,c) ) {
by just one character and the two have very different behaviour. The
presence of parens around the assignment is the heuristic GCC uses to
determine whether to warn you about the possibility that your code
contained a common typo.

mlp

 

[CBFalconer]

.... snip ...

Along the same lines GCC suggests parenthesis around constructs
of the form

if( x=mysub(a,b,c) ) {

Any thoughts on why? It seems obvious to me that this is assigning
the return from mysub to x and then testing it...

Because the original intent might have been:

if (x == mysub(a, b, c)) {

and a typo has deleted the second '='. This is a fairly common
error. By adding the extra set of parenthesis the test is on a
single value, i.e. the parenthized expression. This sort of typo
is also the reason for prefering:

if (CONST == var)
rather than:
if (var == CONST)

because dropping one of the '=' chars will trigger an error in the
first case, but not in the second. Unlike the extra parens case,
this will catch the error on any compiler.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Keith Thompson]

This sort of typo
is also the reason for prefering:

if (CONST == var)
rather than:
if (var == CONST)

because dropping one of the '=' chars will trigger an error in the
first case, but not in the second. Unlike the extra parens case,
this will catch the error on any compiler.

Yes. On the other hand, some of us find the "CONST == var" form so
ugly that it's not worth the increase in safety. De gustibus yadda
yadda.

 

[David Wade]

Yes. On the other hand, some of us find the "CONST == var" form so
ugly that it's not worth the increase in safety. De gustibus yadda
yadda.

I found the extra parenthisis round my expression ugly. Some one who was
reviewing the code suggested changing it to say

if (NULL != ( f=myfunc(a,b,c) ) )

which I found very ugly, and unintuitive. The suggestion was that by putting
a comparision in I was making it obviusly a conditional. My view was that I
was free to use conditionals as and when appropriate ....

 

[Richard Bos]

Besides, like setting free()d pointers to null, it's a trap. One day you
_will_ accidentally write if (var1 = var2) (sorry, presumably you'll
write if (var2 = var1)), and you'll have dishabited yourself from
spotting such errors. You will proceed to make yourself look silly in
front of your colleagues who haven't... if you're lucky.

I found the extra parenthisis round my expression ugly. Some one who was
reviewing the code suggested changing it to say

if (NULL != ( f=myfunc(a,b,c) ) )

which I found very ugly, and unintuitive.

Urg. Why not write

if ( ( NULL != ( f=myfunc(a,b,c) ) ) == TRUE )

Richard

 

[Yevgen Muntyan]

Besides, like setting free()d pointers to null, it's a trap. One day you
_will_ accidentally write if (var1 = var2) (sorry, presumably you'll
write if (var2 = var1)), and you'll have dishabited yourself from
spotting such errors. You will proceed to make yourself look silly in
front of your colleagues who haven't... if you're lucky.


Urg. Why not write

if ( ( NULL != ( f=myfunc(a,b,c) ) ) == TRUE )

Some people don't like doing "if (ptr)", they insist that
if (ptr != NULL)
is the right way, and if you have this, you combine it with
if (0 == foo)
and there you go:
if (NULL != (f = myfunc(a,b,c)))
Crazy stuff.

Yevgen

 

[Guest]

Urg. Why not write

if ( ( NULL != ( f=myfunc(a,b,c) ) ) == TRUE )

I know you're not serious, but because (NULL != ( f=myfunc(a,b,c) ) )
is already easily readable as a boolean expression, arguably unlike
( f=myfunc(a,b,c) ).

 

[Richard Bos]

I know you're not serious, but because (NULL != ( f=myfunc(a,b,c) ) )
is already easily readable as a boolean expression, arguably unlike
( f=myfunc(a,b,c) ).

No, I fear not. You are right that I'm not serious, but that's because I
find my proposed alternative no more unreadable than the one which was
suggested to David, and rather less readable than the simple, idiomatic
if (f=myfunc(a, b, c))

Richard