signed/unsigned mismatch

Started by
9 comments, last by Sneftel 18 years, 8 months ago
Is there a serious problem concerning this issue? For example, comparing a signed and unsigned value? What effect does this have?

int v_int;
unsigned int v_uint;
float v_float;

if( v_int < v_float )
  NoComplaint();

if( v_float < v_uint )
  NoComplaint();

if( v_int < v_uint )
  Complain();


I'm curious as to why the compiler is complaining about int differences, yet it doesn't mind at all if I compare floats or doubles against ints or longs. It doesn't make much sense to me. Shouldn't it complain about all of them or none of them? Also, I'm using MSVC. So if there is no good reason for this, is it possible to disable the warning? Thanks
Advertisement
Consider this code:
  signed int i = -1;  unsigned int j = 1;    bool b = i < j;


What do you expect the value of b to be? If you said true, you'd be wrong; the signed int gets turned into an unsigned int, so the value wraps around and becomes a large positive number, which turns out to be greater than 1. This is why comparing signed and unsigned numbers is possibly a problem. You don't get this kind of sign inversion when comparing a double or a float against an int.
Ermm, what about comparing an unsigned int against a float? As far as I know, floats are always signed.

Thanks for the info, though.

edit: Oh, is it possible to default the compiler to convert the unsigned int to signed rather than the opposite?
The unsigned int would be converted to a float before the comparison in that case.
-Mike
unsigned ints get converted to floats. When you convert an int to a float, you lose information in the least significant bits, not in the magnitude or sign.

edit: if both were converted to signed, then you have troubles with very large unsigned values being turned into negative numbers. Same problem, different expression. But as far as I know, that kind of program transformation is not available in MSVC.
Does anyone actually ignore this warning? You most likely catch the unsigned value and convert to signed before comparing, right? So why would the compiler default to the opposite and invert the number?

I guess I'm not looking for an answer to that. I'll just stick to staying clear of unsigned index or count data.

Thanks for the help.
Most of the time, you get this error in situations where you _know_ the signed integer will not be negative. The best thing to do is to assert() that the value is nonnegative, then cast it to unsigned.
I was looking through some old code of mine today and found a bug just like this.

Mr. Creamy
I use negative values to represent errors or invalid data a lot. For example, an index into an array might be -1 to represent that it points to nothing. I usually only used unsigned data when the value is expected to be really high, which rarely happens. I also like using unsigned values to represent sizes and counts, which is why I'm getting this problem a lot. Signed indices against unsigned counts.

I appreciate the information :)
I used to use unsigned integers for sizes and whatnot but tbh it became a nightmare keeping track of what was signed and what was unsigned. so now everything is signed and I can reserve negative values for error codes, as opposed to either reserving zero which is actually a valid index into an array or returning a boolean to indicate error or failure and passing an integer as reference to store the index in.

signed 4tw!

This topic is closed to new replies.

Advertisement