On May 8, 4:44=A0am, Jack Klein <jackkl...@[EMAIL PROTECTED]
> wrote:
> > 1) uc1 gets promoted to a signed int
>
> On many implementations, perhaps including all those you have ever
> used, uc1 gets promoted to signed int. =A0There are implementations were
> uc1 will get promoted to unsigned int because UCHAR_MAX is greater
> than INT_MAX.
Yes, I'm aware. My post was a follow-up to Eric Sosman's post in which
he mentioned the promotion of unsigned char to signed int.
> > 2) The complement is gotten of this signed int
>
> Of course, on implementations where uc1 is promoted to unsigned int,
> the result of the complement is also an unsigned int.
Correct. Just to be pedantic:
The complement of a signed int is a signed int.
The complement of an unsigned int is an unsigned int.
> > 3) When the signed int is converted back to unsigned char, the
> > behaviour is implementation defined.
>
> This is completely wrong regardless of whether unsigned char promotes
> to signed or unsigned int. =A0Assignment of the value of a higher rank
> integer type, whether signed or unsigned, to a lesser rank unsigned
> integer type is 100% completely defined by the C standard. =A0There is
> absolutely no implementation-defined behavior involved.
Sorry yes, you're right. Conversion from signed to unsigned happens
the same way on every system. I'd gotten confused with converting
unsigned to signed. For instance the behaviour of the following is
implementation defined:
int i =3D 72;
unsigned j =3D UINT_MAX;
i =3D j; /* The value that this puts in 'i' is
totally up to the compiler */
> > There's no problem on a two's complement system, and of course most
> > systems are two's complement, but still I'd definitely go with:
>
> > =A0 =A0 uc2 =3D ~(unsigned)uc1;
>
> On implementations where unsigned char promotes to signed int, the
> result of the complement is either a trap representation or
> implementation-defined,
The only implementation-defined thing about it is the amount of 1's at
the start of it, depending on the amount of value-representational
bits in it. We can be sure what's happening with 8 least significant
bits though, regardless of whether is signed or unsigned.
> and that is regardless of the type of
> representation for negative signed integers. =A0But if the complement
> does not produce undefined behavior by generating a trap
> representation, the assignment to unsigned char is always
> well-defined.
Yes it is.
|
