I'm suggesting that there's no big difference between unsigned char and
unsigned int (and unsigned long...) in this case, and, therefore
compiler's behaviour should be consistent.
But there is a difference.
When "x" is an unsigned int, the expression "x < 0" is equivalent to
(unsigned int) x < (unsigned int) 0
which can never be true, whatever "x" is, and results in
warning: comparison of unsigned expression < 0 is always false
When "x" is an unsigned char however, it reads
(int) x < (int) 0
which only cannot happen because of the particular values "x" can take,
and the warning is
warning: comparison is always false due to limited range of data type
Sounds sane to me, and both warning messages are clear.
And in this case I personally
would prefer a warning in both cases with -Wall.
Then please file a PR in bugzilla so your request won't get lost.
It might be that the warning isn't in -Wall because it has too many
false positives. This is just a guess though.
And this wasn't a purely theoretical observation. There is a driver in
the
Linux kernel, that does exactly this: assigns function return code to
an
unsigned int variable, and then checks for "<0"... And the compiler
happily throws the check away. Yes, I will submit a patch, but if
there is
no strong reason against, maybe it would make sense to warn in these
cases.
I can try to shift the blame and say the kernel should be built with
-Wextra . But then people will shout at me again, so I won't.
Segher
