Re: Question re. integral promotion, signed->unsigned
From: Fred Ma (fma_at_doe.carleton.ca)
Date: 01/30/04
- Next message: James Beck: "Re: A situation"
- Previous message: Randy Howard: "Re: [OT] The Deathstation"
- In reply to: Dan Pop: "Re: Question re. integral promotion, signed->unsigned"
- Next in thread: Dan Pop: "Re: Question re. integral promotion, signed->unsigned"
- Reply: Dan Pop: "Re: Question re. integral promotion, signed->unsigned"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Jan 2004 15:37:53 GMT
Dan Pop wrote:
>
> >Why is it OK to reinterpret a signed integral type as
> >its unsigned counterpart? If it's a negative number,
> >then all of a sudden, the reinterpretation yields a
> >large positive number.
>
> Consider the alternative: the unsigned might have to converted to signed,
> but such a conversion isn't well defined if the value of the unsigned
> cannot be represented by the signed. In such cases, the result is
> usually a negative value, and this isn't any better than the actual
> scenario you have described above.
>
> The moral of the story: the programmer MUST know what he's doing when
> combining signed and unsigned operands.
Yes, it certainly seems so.
> >I'm assuming that the signed
> >number is modelled as a 2's complement number, even
> >though it may be implemented differently in hardware.
>
> No need for such an assumption: the result of the conversion is well
> defined, regardless of the representation of negative values.
I use it as a conceptual aid, though I realize that it may
not reflect actual implementation.
> >Likewise, the unsigned is modelled as a straight binary
> >coded decimal (BCD).
>
> The standard does not allow this. The unsigned must be using a pure
> binary encoding.
Sorry, getting my terminology mixed up. I meant binary encoding.
> >Does the sign bit of the 2's
> >complement number becomes the MSB of the unsigned
> >number, with all other bits remaining unchanged?
>
> If the signed value is negative, it is added the maximum value that
> can be represented by the unsigned type plus one. This is true regardless
> of representation, but, if the representation is two's complement, no
> operation needs to be actually performed: the bit pattern of the signed
> is merely reinterpreted as unsigned.
>
> While this conversion is well defined and yields the same result,
> regardless of implementation, converting an unsigned value that cannot
> be represented by a signed type yields an implementation-defined result
> (or, in C99, may even raise a signal). So, the standard has chosen the
> well defined conversion for this case, which is a good thing.
Yes, and if the standard had defined it the other way (so that
converting unsigned->signed yields a reinterprettation of the
potentially fictitious 2's complement representation), then that would
be well defined too. It seems like an arbitrary choice. Thanks
for confirming how it works.
Fred
-- Fred Ma Dept. of Electronics, Carleton University 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6
- Next message: James Beck: "Re: A situation"
- Previous message: Randy Howard: "Re: [OT] The Deathstation"
- In reply to: Dan Pop: "Re: Question re. integral promotion, signed->unsigned"
- Next in thread: Dan Pop: "Re: Question re. integral promotion, signed->unsigned"
- Reply: Dan Pop: "Re: Question re. integral promotion, signed->unsigned"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
