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!)