[Bug c/92507] New: False positives with -Wsign-compare

[david at westcontrol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92507

            Bug ID: 92507
           Summary: False positives with -Wsign-compare
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david at westcontrol dot com
  Target Milestone: ---

The -Wsign-compare warning is useful for spotting potentially dangerous code. 
It is not always easy to know how the operands of a comparison will be
promoted, and whether the comparison will have the same meaning in the C
language as it has mathematically.  But if the values on both sides are
non-negative, then there is never going to be a problem.

This pattern here occurs in a lot of code, where you have an "int" loop
variable and an unsigned type for the limit - perhaps coming from a sizeof
expression:

void foo(void) {
    const unsigned int n = 10;
    for (int i = 0; i < n; i++) { }
} 


Typically, the compiler knows the value of the limit at compile time. 
Certainly it knows it is non-negative (it is an unsigned type).  And the
compiler can see that the loop variable is always non-negative (as long as
-fwrapv is not in effect).

This kind of code is a big cause of false positives for -Wsign-compare, and
means you either need to use more unsigned types than might be natural, or add
casts, or disable the warning.

Another possible way to handle this is for the compiler to treat "n" in the
example above as an "int" for the comparison.  The compiler knows the value of
"n", and can see that this transformation would be safe.  (And if "n" is too
big to fit in an "int", then we really do want a warning!)