在C / C ++中从int32转换为char时出现垃圾

Question

I am using a simple code to convert an uint32_t variable to char.

uint32_t len = 4 + data.length(); //data is a string
char pop1 = len & 0xff;
char pop2 = (len >> 8) & 0xff;
char pop3 = (len >> 16) & 0xff;
char pop4 = (len >> 24) & 0xff;     //also tried the same thing with memcpy

printf("%02x \n",pop1);
printf("%02x \n",pop2);
printf("%02x \n",pop3);
printf("%02x \n",pop4); 

Output :

ffffff81
02
00
00

I fail to understand why the junk is added to the first byte. When I use unsigned char instead, no junk is added. In my understanding both char and unsigned char are 8-bits, then why the char is treated like a 32-bit value. I am using VS2015 on a 64 bit Windows machine. I want to use the char array for the send function of WinSock2.

send(ConnectSocket, sendbuf, size_to_send, 0); // sendbuf is a char array

Answer 1

When used in an expression, a char is first promoted to int . So if the value of the char value is negative, that value is preserved when it is converted to int , and that is what you see when you print.

You can either cast the value to unsigned char to have it take on a positive value, or you can use the hh modifier on the %x format specifier to have it treat the value as an unsigned char .

printf("%02hhx \n",pop1);
printf("%02hhx \n",pop2);
printf("%02hhx \n",pop3);
printf("%02hhx \n",pop4);

Answer 2

When a value of a small integer type (like char ) is passed as an argument to a vararg function (like printf ) it is promoted to an int

This promotion can include sign extension if the small type is signed .

On two's complement systems (which is the vast majority of computers a long time) that mean the int will be padded with 1 bits, which when printed as an unsigned int in hexadecimal will manifest as f .

The simple solution is to not use char , but preferably uint8_t or an explicit unsigned char type for your variables.

Answer 3

Think of all the type changes and conversion happening. There are at least 4.

0xff , an int is converted to uint32_t , then the & occurs. No problems here.

len & 0xff;

Then that result is assigned to a char , a signed char in OP's case. That assigns a 0x81 (129) that is out-of-range to the char --> Implementation defined behavior . A common result simply passes the smallest bits.

char pop1 = len & 0xff;

why the char is treated like a 32-bit value (?)

It is not treated yet as a 32-bit unsigned value, but as an 8-bit signed value.

Then code pass char pop1 (with maybe a value of -127) to printf(); and incurs an default argument promotion as an argument to the ... function. printf() receives an int with the value of -127.

printf(...,pop1);

printf("%02x \\n",pop1); expects an unsigned and not an int . As the value of -127 is not representable as both an int and unsigned , (c11 §6.5.2.2 6), the conversion specifier is not valid with that argument and the result is undefined behavior (UB). (§7.21.6.1 9). What typically happens is that the bit pattern of -127 passed as an int is interpreted as the bit pattern for an unsigned and result in "ffffff81" .

printf("%02x \n",pop1);

---

To avoid the implementation defined behavior and the UB, recommend the below. For effective unsigned code, use clearly unsigned types, objects and constants.

unsigned char pop1 = len & 0xffu;
// or
uint8_t pop1 = len & 0xffu;