integer-promotion

I am surprised by C++'s behavior when applying bit-wise not to an unsigned char. Take the binary value 01010101b , which is 0x55 , or 85 . Applying bit-wise not on an eight bit representation should yield 10101010b , which is 0xAA , or 170 . However, I cannot reproduce the above in C++. The following simple assertion fails. assert(static_cast<unsigned char>(0xAAu) == ~static_cast<unsigned char>(0x55u)); I printed the values of 0x55 , 0xAA , and ~0x55 (as uchar) with the following code. And it reveals that the bit-wise not does not do what I expect it to do. std::cout << "--> 0x55: " << 0x55u <

Till now I was believing that there is no use of unary + operator. But then I came across with following example: char ch; short sh; int i; printf("%d %d %d",sizeof(ch),sizeof(sh),sizeof(i)); // output: 1 2 4 printf("%d %d %d",sizeof(+ch),sizeof(+sh),sizeof(i)); // output: 4 4 4 Does it mean + is doing type conversion here? Because it is behaving same as following printf("%d %d %d",sizeof((int)ch),sizeof((int)sh),sizeof(i)); // output: 4 4 4 This forces me to think + is doing type conversion. But then I try it on double double f; printf("%d %d",sizeof(+f),sizeof((int)f),sizeof(f)); // output:

Consider following example: #include <stdio.h> int main(void) { unsigned char a = 15; /* one byte */ unsigned short b = 15; /* two bytes */ unsigned int c = 15; /* four bytes */ long x = -a; /* eight bytes */ printf("%ld\n", x); x = -b; printf("%ld\n", x); x = -c; printf("%ld\n", x); return 0; } To compile I am using GCC 4.4.7 (and it gave me no warnings): gcc -g -std=c99 -pedantic-errors -Wall -W check.c My result is: -15 -15 4294967281 The question is why both unsigned char and unsigned short values are "propagated" correctly to (signed) long , while unsigned int is not ? Is there any

unsigned char a, b; b = something(); a = ~b; A static analyzer complained of truncation in the last line, presumably because b is promoted to int before its bits are flipped and the result will be of type int. I am only interested in the last byte of the promoted int - if b was 0x55, I need a to be 0xAA. My question is, does the C spec say anything about how the truncation happens , or is it implementation defined/undefined? Is it guaranteed that a will always get assigned the value I expect or could it go wrong on a conforming platform? Of course, casting the result before assigning will

When is it ever the case that a signed integer cannot represent all the values of the original type with regards to integer promotion? From the text K&R, C Programming Language, 2nd Ed. p. 174 A.6.1 Integral Promotion A character, a short integer, or an integer bit-field, all either signed or not, or an object of enumeration type, may be used in an expression wherever an integer may be used. If an int can represent all the values of the original type, then the value is converted to int; otherwise the value is converted to unsigned int . This process is called integral promotion. This code