Re: Wfutile-unsigned-comparison (PR7651 Define -Wextra strictly in terms of other warning flags)

["Manuel LÃpez-IbÃÃez" <lopezibanez at gmail dot com>]

On 24 Dec 2006 17:58:57 +0100, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:

> Instances of the warning I was thinking of are in the function
> shorten_compare(), c-common.c.  grep for "always true".
> I now remember that there have been several requests to "name" that
> diagnostic, i.e. control it by an option.  I think the diagnostic your
> patch was addressing and this diagnostic are logically the same.

Correct. There are two unconditional warnings for

short y;
if (y < 1000000) /* { dg-warning } */

However, I have just found:

@item -Walways-true
Warn about comparisons which are always true such as testing if
unsigned values are greater than or equal to zero.  This warning is
enabled by @option{-Wall}.

And the unnamed warning in Wextra is:

An unsigned value is compared against zero with @samp{<} or @samp{>=}.

I first thought that the correct solution would be to unify all of
them under Walways-true, but after researching the history behind each
of them, that seems a particularly bad idea. Walways-true was
introduced to warn about using the address of a function in a test,
such as "if (function)" instead of "if (function ())". This was a
request from kernel-devs [1]. On the other hand, warning about "(x >
0)" just because "x" is unsigned seems a bit noisy to the kernel-devs
themselves [2] (and also to me).

I see two other solutions here:

1) We get rid of "An unsigned value is compared against zero with
@samp{<} or @samp{>=}" warnings. This is the simplest and least impact
solution. We don't even have testcases for this and some users really
dislike this warning. We could also update the description of
Walways-true to match its current behaviour.

2) We give it a name different from Walways-true
(Wunsigned-comparison-always-true). If you can come up with a better
descriptive name, I am all for it. This will also imply updating the
description of Walways-true and renaming it
(Waddress-comparison-always-true would be an apter name for it) to
avoid confusion. Obviously, this will have a greater impact in whoever
is currently using Walways-true or Wno-always-true.

I could do a bit more "svn blame" research to find out how the current
situation was reached, so we can involve the people that took the
decisions, if you think it is necessary.

Any thoughts?

[1] http://gcc.gnu.org/ml/gcc/2003-10/msg00414.html
[2] http://kerneltrap.org/node/7434