Re: warning: comparison between signed and unsigned integer expressions

On Apr 23, 2010, at 09:11 , Paul Sargent wrote:

> On Tue, Apr 20, 2010 at 23:14, Clark Cox <[email protected]> wrote:
>> On Tue, Apr 20, 2010 at 1:59 PM, Stephen Hoffman <[email protected]> wrote:
>>> Have a look around for the value-preserving and unsigned-preserving discussions; current C tends to be value-preserving.
>> 
>> The value-preserving behavior is mandated by the C standard wherever possible.
> 
> I feel I should know this, but I had to do a test to find what exactly
> you meant by "value-preserving".
> 
> int a;
> unsigned int b;
> 
> a = -1;
> b = (int) a;
> 
> What is 'b'?
> 
> As it turns out, it's 4294967295 or 0xFFFFFFFF
> 
> BTW for the original poster, if all you're doing is equality
> comparisons (or not equal) a simple case tends to be fine, just be
> careful with < & >. -1 suddenly becomes greater than zero.



Anthropomorphizing what happens: the C compiler looks at the values that can be stored in whatever current wad of data you're working with, and then goes looking for the next-larger wad of data that allows all values to fit, irrespective of the sign bit.   This change to value-preserving from the signed-preserving behavior of older C implementations causes brain-pain for those of us that learned or that are working with signed (or unsigned) data, and for the piles of K&R-1 C code and the piles of old ANSI C and pre-ANSI C source code that's still around, or that are porting code around.  

Some boxes have short and int the same size, and some don't.  Some have long and long long as the same, and some don't.   

It's been my experience that you can't simply look at the "type" and be sure what happens when promoting in ported code.  You have to know what's underneath the type; the details of the implementation of the type on the target box.  Then there's the "fun" of signed versus unsigned; with the compilers that (correctly) flag "unsigned integer less than zero" conditionals, for instance.

The other thing that hits here is the endian storage of data; records or data or such that are transported between systems via network connection or via file or such.  This hits in some obvious ways (endianness, boxes that don't use IEEE floating point), and in some more subtle ways (where folks are storing character data in integers).  All arguments of whether this storage should be used to the side, there's a whole pile of C code around that does slam into FP errors or endian errors or what happens to derail when integer-based character data gets swizzled in from its expected endianness.

I won't even get into the "fun" involved when you're not working with eight-bit-bytes, or porting to a middle-endian box or a processor that's bi-endian.  That can get weird.