Jump to content
  • Advertisement
Sign in to follow this  
Kest

signed/unsigned mismatch

This topic is 4834 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I was looking through some old code of mine today and found a bug just like this.

Mr. Creamy

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!