strange output when formatting char

[MagnusBL]

Hi I am just experimenting a little with typecasting and string formatting. Given the small program using MFC and compiled in Visual Studio Express.

[code]

short int i = 128;
char c;
CString str;
int len;

c = i; //move first byte of int to char.
str.Format("Value of char is %#X", c);

CClientDC dc(this);
len = str.GetLength();
dc.TextOutA(10,10,str,len);

[code]

when i = 127 the output is (as expected) 0X7F. However when i = 128 the output is 0XFFFFFF80. Where are all these F's coming from? Does it have anything to do with the CString class

Suddenly it appears that c is a 4 byte value. I understand that something (strange) should happen since char should only hold -128 to 127. But I would rather just expect 0X80 (binary 1000 0000). Which is what you get when i = -128.

Kind regards

Magnus

[weaknessforcats]

Those F's are the result of having a negative value. Negative integer values are usually stored in 2's complement format.

Here is 5 in binary:

0101

Let's assume the lead 0 is the sign bit.

To get the 2's complement you a) reverse all bit values and b) add 1:

0000 0101 -> 5
0000 1010 -> reversing bit values
0000 0001 -> the 1 to add
1111 1011 -> the 2's complement. This is -5

Notice the sign bit is turned on. In hex this where your F comes in. The above is 0xFB.

To get back the original 5 just repeat the process:

1111 1011 -> -5
0000 0100 -> reversing bit values
0000 0001 -> the 1 to add
0000 0101 -> the 2's complement. This is +5 back again.

[MagnusBL]

@weaknessforcats
Thanks for the quick an enlightening answer, but I don't quite understand yet:

int i = 128 would be stored in binary as: 1000 0000. (the first byte in the int, that is)

I assume c = i would give c a binary representation of 1000 0000. Interpreting this in decimal using 2s compliment would give -128. But the hex representation of binary 1000 0000 is 0X80. I still don't see where the F's are coming from (and why there are so many of them)?

Magnus

[weaknessforcats]

OK, let's take a 4-byte (32 bits) int with 128:

0000 0000 0000 0000 0000 0000 1000 0000

This is 0x00000080.

To get -128 , follow the rules:

0000 0000 0000 0000 0000 0000 1000 0000 -> 128
1111 1111 1111 1111 1111 1111 0111 1111-> reversing bit values
0000 0000 0000 0000 0000 0000 0000 0001 -> the 1 to add
1111 1111 1111 1111 1111 1111 1000 0000-> the 2's complement. This is -128
Notice the sign bit is turned on. In hex this is 0xFFFFFF80.

[donbock]

The type char is signed for some C compilers and unsigned for others -- this is explicitly labeled as implementation-dependent behavior. It appears from your result that char is signed for your compiler.

Let's assume that your platform uses two's-complement encoding for signed integers. Let's further assume that char is 8 bits, short is 16 bits, and int is 32 bits. These are reasonable assumptions.

The value 128 is too big to fit in a char ... that value overflows the char. What ends up in the char after the overflow is undefined behavior; however, it is not uncommon for the upper bits that don't fit to be thrown away. That is apparently what happened in your program, but you cannot rely on that to happen all the time.

Because of the way your program handles overflow, the char contains -128. Suppose we assign the char to an int variable. There is no overflow (-128 easily fits in an int). The int also contains -128.

When you pass arguments to a function those arguments are implicitly cast to the argument types as declared in the function prototype. If there is no function prototype (and also for arguments that map to an ellipsis in the prototype) then the default promotions occur. The default promotion for char and short argument values is to cast to int.

The function prototype for printf contains an ellipsis (see below). Therefore the default promotions occur for all arguments except the first.

int printf(const char *fmt, ...)

Your printf line passes the char as an argument. It is as if you assigned the char to an int. As a result, printf sees -128 in a 32-bit variable. A 32-bit value is expressed in 8 hexadecimal digits. That's why you see so many F's.

[MagnusBL]

Wow! Thanks a lot to both donbock and weaknessforcats. That sums it up. First and overflow when putting 128 into unsigned char making it -128. Then a promotion of -128 in the function to an int. Accounting for all the F's and the4-byte appearance.

Magnus