[ofa-general] Re: dealing with gcc 'comparison is always false' warnings

Satyam Sharma satyam.sharma at gmail.com
Wed May 30 10:00:14 PDT 2007


[ Sorry, the threading broke because the subject changed,
so I missed seeing this mail earlier. ]

On 5/30/07, Roland Dreier <rdreier at cisco.com> wrote:
>  > However, gcc is _just as correct_. It is only crying about seeing a condition
>  > that the programmer could have written with some purpose in mind but which
>  > is being completely compiled away by it when generating the code because
>  > of it being a tautology / contradiction ...
>
> Well, OK, but there's lots of things gcc could warn about.  How about
>
>         while (1) { ...

Umm ... perhaps because gcc does not compile away any code for
such cases, but only the condition? Or because gcc knows this is
a common idiom in a *lot* of C code? I don't know (or care!) ... the
precise cases for which the warning is emitted would be known only
by reading gcc sources (which I have no intention of doing :-)

> By your argument gcc should warn that '1' always evaluates to true.

Note that my "argument" was about conditions that weren't as
simplistic as #if 0 or while (1) and that involved not merely 1 or 0,
but variables whose values might not be available at compile-time ...

> Or how about
>
> #if 0
>
> why shouldn't the preprocessor warn that the conditional is always false?

Perhaps because gcc knows programmers often use this common
method to disable some code?

I can't answer all these questions, of course (better ask the gcc folks),
but I don't care either. Clearly, none of the above are any reason why
gcc should *not* complain when it sees a _seemingly_ meaningful
condition conceivably written by the programmer with something in
mind but being completely optimized away by it.

[ BTW, perhaps the reason why the gcc folks did *not* put a warning
for while (1) or #if 0 is also because they know that programmers often
write such conditions with something meaningful in mind. ]

>  > No, shutting gcc up wouldn't be the right thing, IMHO. These warnings are
>  > a good reminder to the programmer to go and see if there is a real bug
>  > somewhere and if something really needs to be done with the code (could
>  > be simply to change the type of a variable to signed that was mistakenly
>  > declared unsigned, f.e.).
>
> OK, but suppose I looked at it and there's no bug.  Leaving the
> warning has a cost too: it hides useful warnings (that might be
> showing real bugs) in all the clutter.

Agreed, this warning emits a lot of false positives. But this warning isn't
enabled with -Wall either, or is it (now)? I remember the only way to
enable this was with -Wextra, and last I heard the top-level Makefile
did not specify that ... (?)

Satyam



More information about the general mailing list