为什么在C编程中char a = -1与无符号char b = -1不同

Question

i have written a small program below.

#include <stdio.h>
main(){
    char a=-1;
    unsigned char b=-1;
    printf("%d %d\n",a,b);
    printf("%x %x\n",a,b);
    if(a==b) printf("equal\n");
    else printf("not equal\n");
}

The output of the prog is :

-1 255
ffffffff ff
not equal

since char is only one byte and -1 is represented in 2's complement form, i thought that 0xff will be stored in both a & b and hence both should be equal. Can anyone let me know why they are different and why hex rep'n of a is 0xffffffff & not 0xff. i got a related link http://embeddedgurus.com/stack-overflow/2009/08/a-tutorial-on-signed-and-unsigned-integers/ but i couldn't get the answer. any help will be greatly appreciated. thanks.

Answer 1

They are the same. Or rather, their underlying representation is the same (under the assumption that your compiler use two-complement form).

On the other hand, the values they represent are -1 and 255.

When you print them, they are extended to the data type int . unsigned char is zero-extended whereas a signed char is sign extended, which accounts for the differences you see.

The same extension occurs when you compare the two values. a == b don't compare the underlying representations, instead, it extends both values to int so it compares 255 with -1, which isn't equal.

Note that a plain char may be either signed or unsigned. In your environment, it is obviously signed.

Answer 2

The char type is something of an anomaly in that it is not the same as either signed char or unsigned char (unlike the other integer types - short , int , long , etc - which are implicitly signed unless explicitly declared unsigned ). Whether char is actually signed or not is implementation-dependent, and some compilers even let you specify the signedness via a command line switch.

Bottom line: never assume that char is signed or unsigned - if you actually require a signed or unsigned 8 bit quantity then use signed char or unsigned char explicitly, or better still, use int8_t or uint8_t from <stdint.h> .

Answer 3

A signed int is signed, an unsigned int is unsigned. If you use just int , it implies signed int . Same is true for short , long or long long . Yet it isn't true for char . A signed char is signed, an unsigned char is unsigned, but just char may be either signed or unsigned. The data type char is supposed to hold a "character", hence the name, so it's not "really" an integer type to hold an integer number to be used in calculations. Of course a character is in reality an integer of some kind but of which kind is implementation dependent (the C standard does not force any specific kind). So if you want to use the char type for integer values (also used in calculations), always use signed char or unsigned char explicitly and only use just char when you are really dealing with characters or when it makes absolutely no difference for your code if char is signed or unsigned.

The comparison fails because your implementation defines char to be in fact signed char , so you are comparing a signed char to an unsigned char in your final if statement. Whenever you are comparing two integers of different type, the compiler converts both values to the same type according to the rules of the C standard before it actually performs the comparison. In your case, this means the C compiler actually does tho following:

if((int)a==(int)b) printf("equal\n");
    else printf("not equal\n");
}

And now it should be obvious why those two values don't match. (int)a has a value of -1 , however (int)b has a value of 255 , and these two values are not equal.

According to the rules of type promotion , char (in your case signed) is promoted to int and unsigned char is also promoted to int . The ISO C 2011 standard says:

If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions.) All other types are unchanged by the integer promotions.

The integer promotions preserve value including sign. As discussed earlier, whether a ''plain'' char is treated as signed is implementation-defined.

Answer 4

While there is some ambiguity around a plain "char" (see Is char signed or unsigned by default? ) that's not the only thing that's going on here I think.

A literal -1 is an integer, it won't (sizeof(int)>sizeof(char), for arguments sake) "fit" into a char.The two-complement bit pattern 0xffff (32 bit int for arguments sake) is truncated and copied here.

When you call printf() the parameters are promoted to integer type, a signed type is "sign-extended", but the unsigned "b" is not, and zero padded. When you use "==" with two distinct types a similar (but not necessarily identical) type conversion is performed (aka the "usual arithmetic conversions").

See also Default argument promotions in C function calls and Signed and unsigned, and how bit extension works in C .