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;
}

[mark_bluemel]

On 14 Feb, 17:16, "[e-mail]"
<[e-mail]:

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]

In article <11**********************@a34g2000cwb.googlegroups .com>,
[e-mail] <lo***************@gmail.comwrote:

>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.

--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Ben Pfaff]

"[e-mail]" <lo***************@gmail.comwrites:

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.

--
Peter Seebach on C99:
"[F]or the most part, features were added, not removed. This sounds
great until you try to carry a full-sized printout of the standard
around for a day."

[christian.bau]

On Feb 14, 5:31 pm, Ben Pfaff <[e-mail]:

"[e-mail]" <[e-mail]:

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)

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

[Ben Pfaff]

"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:

On Feb 14, 5:31 pm, Ben Pfaff <[e-mail]:

>"[e-mail]" <[e-mail]:

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)

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.
--
Here's a tip: null pointers don't have to be *dull* pointers!

[Old Wolf]

On Feb 15, 6:36 am, [e-mail] wrote:

>
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...]

On 2ÔÂ15ÈÕ, ÉÏÎç1ʱ31·Ö, Ben Pfaff <[e-mail]:

"[e-mail]" <[e-mail]:

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.
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:

"christian.bau" <ch***********@cbau.wanadoo.co.ukwrites:

<leap year expressions snipped>

>>
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.

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[David Wade]

"[e-mail]" <lo***************@gmail.comwrote in message
news:11**********************@a34g2000cwb.googlegr oups.com...

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.

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;
}

[David Wade]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:eq**********@canopus.cc.umanitoba.ca...

In article <11**********************@a34g2000cwb.googlegroups .com>,
[e-mail] <lo***************@gmail.comwrote:

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.

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...

--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Mark L Pappin]

"David Wade" <g8***@yahoo.comwrites:

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote:

>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...

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]

David Wade wrote:

>

.... 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]

CBFalconer <cb********@yahoo.comwrites:
[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[David Wade]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

CBFalconer <cb********@yahoo.comwrites:
[...]

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.

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 ....

--
Keith Thompson (The_Other_Keith) ks***@mib.org

<http://www.ghoti.net/~kst>

San Diego Supercomputer Center <*>

<http://users.sdsc.edu/~kst>

We must do something. This is something. Therefore, we must do this.

[Richard Bos]

"David Wade" <g8***@yahoo.comwrote:

"Keith Thompson" <ks***@mib.orgwrote in message

CBFalconer <cb********@yahoo.comwrites:

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.

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]

Richard Bos wrote:

"David Wade" <g8***@yahoo.comwrote:

>"Keith Thompson" <ks***@mib.orgwrote in message

>>CBFalconer <cb********@yahoo.comwrites:
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.

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 )

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

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Bos wrote:

"David Wade" <g8***@yahoo.comwrote:

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 )

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]

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:

Richard Bos wrote:

"David Wade" <g8***@yahoo.comwrote:

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 )

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