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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a781481a0705301000r35e2dde7x8c90ba7b0497e4ef@mail.gmail.com>
Date:	Wed, 30 May 2007 22:30:14 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Roland Dreier" <rdreier@...co.com>
Cc:	linux-kernel@...r.kernel.org, openib-general@...nib.org
Subject: Re: [ofa-general] Re: dealing with gcc 'comparison is always false' warnings

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

On 5/30/07, Roland Dreier <rdreier@...co.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/