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 [EMAIL PROTECTED]
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
