GCC 3.3.1, new warnings with <limits>
leimy2k at mac.com
Sun Jul 13 12:29:45 PDT 2003
> 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
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
unsigned would also, logically, be encouraged to behave as a 2's
number. Cute way to make the standard "seem" flexible. The overhead
conversion is often overlooked in coding it seems... On some platforms
PPC going from int to float takes a lot longer than one might think...
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
for me and hopefully others.
> <Insert your favourite quote here.>
> Erik Trulsson
> ertr1013 at student.uu.se
More information about the freebsd-current