Have a read about Two's complement, it's not just an operation - it's the representation of signed numbers.
I'll give you a start
char x = 0xFF;
On most systems, char is default signed (although this is not guaranteed). 0xFF represented in binary is 1111 1111. The first bit is set to '1' in the signed character, this implies that the value is in fact a negative value. Implementing two's complement, you will find that the variable 'x' is equal to negative 1.
This takes care of the explanation for one of the cases. What do you think happens when you assign a negative signed integer to a unsigned integer?
This post has been edited by jjl: 18 January 2013 - 10:51 PM
"Try it and see" is a dangerous philosophy that leads to unportable code. This code invokes implementation-defined behaviour as indicated by §18.104.22.168 of the C standard. Consider if the implementation were to decide to raise a signal indicating that the code above has performed a computational error, and the signal handler were to return. This code would, for that implementation, be in the realms of undefined behaviour.
@jjl: Have you ever heard of ones' complement or sign and magnitude?
Furthermore, this code depends upon CHAR_BIT. There are existing systems where CHAR_BIT is 16, and a signed char can store values between the range of -32767 and 32767. On such systems, char x = 0xFF; would result in x storing the positive value 255. This has nothing to do with signed representation.
The output for that program is entirely implementation defined.
"Try it and see" is a dangerous philosophy that leads to unportable code.
If someone is going to post some code (especially something basic) and ask what it does without having made any apparent effort, I think running it is a valid way to figuring it out. Once the result is known, explanation is a good next step.
There are several things wrong with the code provided. A couple of these problems actually lead to undefined behaviour. The use of the "%x" format specifier in the printf() is one example of undefined behaviour. The "%x" format specifier is only valid for an unsigned int value. And the C standard states that using a specifier that doesn't match the type is undefined behaviour. From Section 22.214.171.124 The fprintf function.
If a conversion specification is invalid, the behavior is undefined.282) If any argument is not the correct type for the corresponding conversion specification, the behavior is undefined.
Since the OP stated that a char is a signed char, assigning a value of 0xFF will produce undefined behaviour, if this char is also an 8 bit value, since overflow of a signed integral value is undefined.
A decent compiler should reject the code as provided, since no include files were used the arguments for the printf() call should not match and it should be able to detect the problem with the signed char overflow. So in my opinion the telling the OP to try to compile this program is a valid response to the code dump.
By the way here are the errors and warnings my compiler produced:
main.c|2|error: return type defaults to ‘int’|
main.c||In function ‘main’:|
main.c|4|warning: overflow in implicit constant conversion [-Woverflow]|
main.c|8|error: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration]|
main.c|8|warning: incompatible implicit declaration of built-in function ‘printf’ [enabled by default]|
||=== Build finished: 2 errors, 2 warnings ===|