Unsigned and Signed Comparison

Comparison operation on unsigned and signed integers

Binary operations between different integral types are performed within a "common" type defined by so called usual arithmetic conversions (see the language specification, 6.3.1.8). In your case the "common" type is unsigned int. This means that int operand (your b) will get converted to unsigned int before the comparison, as well as for the purpose of performing subtraction.

When -1 is converted to unsigned int the result is the maximal possible unsigned int value (same as UINT_MAX). Needless to say, it is going to be greater than your unsigned 1000 value, meaning that a > b is indeed false and a is indeed small compared to (unsigned) b. The if in your code should resolve to else branch, which is what you observed in your experiment.

The same conversion rules apply to subtraction. Your a-b is really interpreted as a - (unsigned) b and the result has type unsigned int. Such value cannot be printed with %d format specifier, since %d only works with signed values. Your attempt to print it with %d results in undefined behavior, so the value that you see printed (even though it has a logical deterministic explanation in practice) is completely meaningless from the point of view of C language.

Edit: Actually, I could be wrong about the undefined behavior part. According to C language specification, the common part of the range of the corresponding signed and unsigned integer type shall have identical representation (implying, according to the footnote 31, "interchangeability as arguments to functions"). So, the result of a - b expression is unsigned 1001 as described above, and unless I'm missing something, it is legal to print this specific unsigned value with %d specifier, since it falls within the positive range of int. Printing (unsigned) INT_MAX + 1 with %d would be undefined, but 1001u is fine.

Is comparing signed and unsigned integer safe?

Comparing unsigned with signed can have serious problems, e.g.

std::string( "Bah" ).size() < -5

… will always be true.

That's the reason why you get warnings, but the compiler isn't smart enough, in the the time frame it has allotted, to see that any particular such comparison would be safe.

Now to your bullet point questions.

” is there any benefit, performance or safety-wise, to always using unsigned over signed integers where applicable?

Yes, for correctness, avoiding UB. But, “applicable” is where you do bit level things. For numbers always prefer signed integer, or floating point type.

” in what cases, if any, comparing signed and unsigned integer can result in errors or unexpected behavior?

When unsigned wrap-around gets involved, typically by implicit promotion of an operand from signed to unsigned.

” if there is no good reason to worry about those warnings, is there any historical reason, why this information could be useful to developers in the past?

Not applicable.

How to perform signed comparison between unsigned operands?

Since you're using stdint include, you could convert the operands to 64 bit signed values, and compare that, no risk that any of the terms to the right become negative, and we have to cast the left operand to signed integer to avoid undefined/implementation behaviour when comparing signed/unsigned:

if ((int64_t)empty_bucket < ((int64_t)base_bucket + ((int64_t)hop_size - 1) - (int64_t)ht_size))

To sum it up:

no risk of overflow (I may have cast a little too much on the right side)
comparison between signed entities
On the downside, 64 bit conversion may have a negative impact on the performance on a 32 bit architecture

Detecting signed vs. unsigned comparison bugs

You can use -Wsign-compare with -Wsign-conversion.

The first one warns you when you compare signed values with unsigned ones. The latter warns you about implicit conversions from unsigned to signed and from signed to unsigned.

In your case -Wsign-compare won't do anything because of integer promotion, while -Wsign-conversion will warn about implicit conversion in s16 = u16.

comparing unsigned vs signed does not make a warning (using const)

I'd say it's a compiler bug in the -Wsign-compare option.

Test by compiling your example with -Wall -Wextra -O3. With -O3 added, the warning suddenly goes away in the const case. Even though the generated machine code with or without const is identical. This doesn't make any sense.

Naturally, neither const nor the generated machine code has any effect on the signedness of the C operands, so the warning shouldn't come inconsistently depending on type qualifiers or optimizer settings.