1 Feb
2012
1 Feb
'12
7:48 a.m.
Mouse wrote:
Only for negative values, in which case the result can
be whatever the
implementation finds convenient (undefined or implementation-defined).
Chuck Guzis
wrote:
So, on a system with, say, sign-magnitude arithmetic,
masking the
sign off after every operation to force a positive result is
perfectly legitimate way to implement the unsigned type.
That's definitely not allowed for unsigned char, which is not allowed to
have any padding bits. If an unsigned char has n bits, it must be able
to represent all values from 0 to (2^n)-1.
For the larger integer types it is possible, as all larger integer types
are allowed to have padding bits. The requirement is that any bit that
is a value bit (and not a sign bit or padding bit) in a signed type must
"have the same value as the same bit in the object representation of the
corresponding unsigned type" (ISO/IEC 9899:1999 section 6.2.6.2 paragraph 2)
Due to the requirements for the integer size limits (limits.h, section
5.2.4.2.1), if you want to do that your short and integer will have to
be at least 17 bits, long will have to be at least 33 bits, and long
long will have to be at least 65 bits. This would be somewhat
reasonable on an 18-bit machine or 36-bit machine, with 9-bit chars, and
the other integer types being 18-bit, 36-bit, and 72-bit.
However, I think most people would prefer an implementation where the
unsigned integer types did not have padding bits, and could represent
the full range possible with the width of the type.