Interesting! n & 1 == 1
is the same as n & 1, since "1==1" is always true, which is the value 1. If the bottom bit of n is set, this will evaluate to 1, which is also the value "true". So, while clang is perfectly correct about the problem, the code generated is identical with and without the parentheses. This statement should just be return (n & 1); This is simpler to understand, and won't generate spurious warnings. Adding parentheses like this: return ((n & 1) == 1) ? true : false; is a waste of time, confusing, and unnecessary. -- Nick Stoughton On Wed, Jan 4, 2012 at 7:10 PM, Ryan Schmidt <[email protected]>wrote: > Trying to build groff 1.21 with clang 3.0 (or 2.9) on OS X 10.6.8 I get > this warning, which seems like it's pointing out a real problem: > > > input.cpp:998:13: warning: & has lower precedence than ==; == will be > evaluated first [-Wparentheses] > return (n & 1 == 1) ? true : false; > ^~~~~~~~ > input.cpp:998:13: note: place parentheses around the == expression to > silence this warning > return (n & 1 == 1) ? true : false; > ^ > ( ) > input.cpp:998:13: note: place parentheses around the & expression to > evaluate it first > return (n & 1 == 1) ? true : false; > ^ > ( ) > 1 warning generated. > > > I notice you've had a fix for this in your repository for half a year > already. Will you release a new version of groff soon? We would like to > benefit from all the improvements you've made in groff since the release of > 1.21 one year ago. > > > > > _______________________________________________ > bug-groff mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-groff >
_______________________________________________ bug-groff mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-groff
