Re: GCC 3.3.1, new warnings with <limits>

>
> C doesn't require two's compliment, but  it encourages it.
>
> If you take a signed value and convert it to the corresponding
> unsigned type , the result must be equal modulo 2^N to the original
> value (where N is the number of bits in the unsigned type. (Ignoring
> any padding bits.)) (Actually it is modulo a value one greater than the
> largest value representable by the unsigned  type, but this amounts to
> the same thing.)
> This means that -1 converted to an unsigned type will always be the
> largest number representable by that unsigned type.
> This is true regardless of how negative numbers are represented.
> For two's complement there is no need to change the representation when
> converting signed to unsigned values, while this can be needed when
> using sign-magnitude or one's-complement.
>

So for the one way conversion of signed to unsigned it will behave like 
2's compliment
all the time. What about back to signed?  I assume that it defaults 
back to the
platform's implementation of the signed type.... which due to the 
conversion to
unsigned would also, logically, be encouraged to behave as a 2's 
compliment signed
number.  Cute way to make the standard "seem" flexible.  The overhead 
of type
conversion is often overlooked in coding it seems... On some platforms 
like the
PPC going from int to float takes a lot longer than one might think... 
but that
is another story :).  [no need to answer this... unless we take it out 
of this thread]


> And to answer the original question:
> It is valid to assume that -1 converted to an unsigned integer type
> will never be equal to 0.
>

No arguments here. :)  Sorry if we wandered off too far.  It was at 
least enlightening
for me and hopefully others.

Dave
>
> -- 
> <Insert your favourite quote here.>
> Erik Trulsson
> ertr1013_at_student.uu.se