On 27/09/2010 07:51, J Decker wrote:
The standards did not leave this open. They define precisely what is
supposed to happen.
Really? I'll have to drop this whole lobbying effort then. That
makes me sad that they didn't define it to be comparing of the numbers
where there are overlaps in signed and unsigned instead of causing all
negative signed values to be wrong.
Your basic problem here is that you are thinking of mathematically ideal
integers and numbers - C works using an approximation that fits a
balance between "real world" numbers and the arithmetic supported by
typical processors.
For example, the standards say explicitly that unsigned integers wrap
modulo 2^n - that doesn't happen with real-world integers.
The compiler is generating the correct code for source written in C. If
the C language doesn't work the way you think here, then you can enable
the warnings to get a message when there are conflicts - you can then
manually and explicitly write the code you want (maybe casting one or
both operands to "long long int").
But if it's not fixed, this warning should definatly be issued at
default warning level. This should be more like 'if this comparison
can be wrong, it will be wrong'.
There is no problem comparing values of signed type with values of
unsigned type if the signed values are known to be nonnegative. Of
course it is sometimes hard to know that; hence the warning. But
enabling the warning by default does not make sense.
It's exactly the fact that 'of course it is sometimes....' that makes
the warning make more sense to be on by default. I don't always know
that I've added an unsigned value to an expression, causing one side
of a comparison to become unsigned, resulting in 100% failure on
negative signed result comparison.
If you don't know what code you are writing, then you should be more
careful in your programming. If your code depends on whether parts of
an expression are signed or unsigned, and it is not entirely clear from
the context, then use explicit casts so that the compiler, the code
author, and other code readers know exactly what is happening.
The compiler cannot spot every possible arithmetic error. What do you
expect the compiler to do with a function like this?
int foo(unsigned int x) {
if ((x + 1) > 0) return 1;
return 0;
}
If "int" worked like real mathematical integers, it would always return
1. If "int" works like it does on most processors, then it will return
0 if i is equal to ((unsigned int) -1).
You have two choices here. You can learn how "int" and "unsigned int"
actually work in C, and program accordingly using casts as necessary and
enabling warnings for safety. Or you can switch to a language which
provides much better checking of this sort of thing, such as Ada.
There are good reasons why the warning is not enabled by default. It is
far from rare in C programs to have mixed use of signed and unsigned
data, and in the vast majority of cases it is done safely. For some
types of programs you want to enable warnings like this and explicitly
add type-casts to remove the warnings, but in most cases the warnings
would be annoying noise that makes it harder to find real errors.
