GCC 3.3.1, new warnings with <limits>
M. Warner Losh
imp at bsdimp.com
Sun Jul 13 12:40:30 PDT 2003
In message: <1046B4F9-B561-11D7-BE3B-0003937E39E0 at mac.com>
David Leimbach <leimy2k at mac.com> writes:
: You keep saying this... where is this "must behave as two's compliment
Read the fine print on the signed to unsigned conversion and you find
that it must be done modulo 2^N. Also, I never stated that the
standard requires the machine use two's complement representation, but
it has to behave as if that were the case.
>From the standard:
18.104.22.168 Signed and unsigned integers
[#1] When a value with integer type is converted to another
integer type other than _Bool, if the value can be
represented by the new type, it is unchanged.
[#2] Otherwise, if the new type is unsigned, the value is
converted by repeatedly adding or subtracting one more than
the maximum value that can be represented in the new type
until the value is in the range of the new type.
The argument runs like this:
o assume int is 32 bits, but the argument can be run for other
o the largest value is 0xffffffff. largest plus 1 is
o -1 increased by 'one more than the maximum value' is
That's behaving as if the type was two's complement.
: > (unsigned int) -1 == 0xffffffff (assuming 32-bit int).
: or with a valid one's compliment C99 compliant system
: (unsigned int) -1 = 0xfffffffe;
That's an invlaid conversion. While -1 might be represented by the
bit pattern 0xfffffffe, "(unsigned int) -1" must evaluate to
: > even on a one's complement's machine, without the standard conversion,
: > the 'type punning' conversion of -1 would yield 0xfffffffe, which is
: > still > 0.
: Correct :). I still don't think C enforces two's compliment.
You are partially right. An 'int' containing '-1' might have a bit
pattern of 0xfffffffe or even 0x800000001, but converting it to
'unsigned' must result in 0xffffffff.
More information about the freebsd-current