Почему результат сравнения int и unsigned int равен 1?

William Astle
December 1, 2017 at 10:16 pm

On most architectures, you’ll get the same results. That’s because most architectures are using two’s complement representation of integers. If you do a naïve cast from signed to unsigned (that is, don’t check for negative first and just treat the bit pattern as a positive number), all negative numbers will be greater than all positive numbers. Note that the same thing should happen even on a 6809.

As you discovered, there’s a really good reason for the signed/unsigned warnings.

The problem here is actually in the C language itself, though. Comparing signed and unsigned *should* be safe and it can be implemented. However, the code for that gets messy and in many cases isn’t actually needed (say if the programmer knows the domain of the signed value will never be negative).

Instead, C went the way that made things easier for the compiler. I think originally casting a negative to unsigned was just “undefined” which means that compiler can technically do anything including emit code to format your hard drive. Most compiler writers just went for the easy thing – treat the bits of the signed value as unsigned. And, poof! You get the behaviour you discovered. Newer C specifications may have made that behaviour more explicit.

Actually, there is a *lot* of stuff in C that is undefined but which any reasonable programmer would expect to behave sensibly. That’s partly why older code generates so many warnings on modern compilers. Compilers have been getting a lot better at warning about undefined behaviours.