Re: GCC 3.3.1, new warnings with <limits>

On Sun, Jul 13, 2003 at 02:28:38PM -0500, David Leimbach wrote:
> >
> >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

Signed to unsigned will always give the same result, regardless of how
negative numbers are represented, yes. (And for two's complement this
is the same as the "natural" way of doing it, while for other
representations some extra work might be needed.)

> all the time. What about back to signed?  I assume that it defaults 
> back to the

If you have try to convert a value to a signed type and the type in
question cannot that value, then the result is implementation-defined.
Implementation-defined means the implementation is free to do whatever
it wants, but it must document what it will do.
Typically implementations won't do anything special but will just keep
the same representation, but this is not something that portable
programs can depend on.

So, on a one's complement machine one would probably have that:
(int)UINT_MAX == 0
(Since UINT_MAX would have the same representation as a negative  zero
on such a machine.)
On a sign-magnitude machine it would probably be
(int)UINT_MAX == INT_MIN
and on a two's complement machine one would probably have
(int)UINT_MAX == -1
but an implementation is also free to trap on integer overflow, just as
it usually does with division by zero. (Or it might do something else.)

Unsigned arithmetic is well-defined in C. Signed arithmetic less so.

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

That depends on how long one thinks it should take, doesn't it? :-)

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

-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013_at_student.uu.se