Re: GCC 3.3.1, new warnings with <limits>

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 
: stated?"

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:

       6.3.1.3  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
	  word sizes.
	o the largest value is 0xffffffff.  largest plus 1 is
	  0x100000000.
	o -1 increased by 'one more than the maximum value' is
	  0xffffffff.

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
0xffffffff.

: > 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.

Warner