signed and unsigned integer in C

Question

I have wrote this program as an exercise to understand how the signed and unsigned integer work in C. This code should print simply -9 the addition of -4+-5 stored in variable c

#include <stdio.h>

int main (void) {
  unsigned int a=-4;
  unsigned int b=-5;

unsigned int c=a+b;
printf("result is %u\n",c);

return 0;
}

When this code run it give me an unexpected result 4294967287. I also have cast c from unsigned to signed integer printf ("result is %u\n",(int)c); but also doesn't work.

please someone give explanation why the program doesn't give the exact result?

Answer 1

That answer is precisely correct for 32-bit ints.

unsigned int a = -4;

sets a to the bit pattern 0xFFFFFFFC, which, interpreted as unsigned, is 4294967292 (2³² - 4). Likewise, b is set to 2³² - 5. When you add the two, you get 0x1FFFFFFF7 (8589934583), which is wider than 32 bits, so the extra bits are dropped, leaving 4294967287, which, as it happens, is 2³² - 9. So if you had done this calculation on signed ints, you would have gotten exactly the same bit patterns, but printf would have rendered the answer as -9.

Answer 2

Using google, one finds the answer in two seconds..

http://en.wikipedia.org/wiki/Signedness

For example, 0xFFFFFFFF gives −1, but 0xFFFFFFFFU gives 4,294,967,295
for 32-bit code

Therefore, your 4294967287 is expected in this case.

However, what exactly do you mean by "cast from unsigned to signed does not work?"

Answer 3

if this is an exercise in c and signed vs unsigned you should start by thinking - what does this mean?

 unsigned int a=-4;

should it even compile? It seems like a contradiction.

Use a debugger to inspect the memory stored at he location of a. Do you think it will be the same in this case?

 int a=-4;

Does the compiler do different things when its asked to add unsigned x to unsigned y as opposed to signed x and signed y. Ask the compiler to show you the machine code it generated in each case, read up what the instructions do

Explore investigate verify, you have the opportunity to get really interesting insights into how computers really work

Answer 4

You expect this:

printf("result is %u\n",c);

to print -9. That's impossible. c is of type unsigned int, and %u prints a value of type unsigned int (so good work using the right format string for the argument). An unsigned int object cannot store a negative value.

Going back a few line in your program:

unsigned int a=-4;

4 is of type (signed) int, and has the obvious value. Applying unary - to that value yields an int value of -4.

So far, so good.

Now what happens when you store this negative int value in an unsigned int object?

It's converted.

The language specifies what happens when you convert a signed int value to unsigned int: the value is adjusted to it's within the range of unsigned int. If unsigned int is 32 bits, this is done by adding or subtracting 2³² as many times as necessary. In this case, the result is -4 + 2³², or 4294967292. (That number makes a bit more sense if you show it in hexadecimal: 0xfffffffc.)

(The generated code isn't really going to repeatedly add or subtract 2³²; it's going to do whatever it needs to do to get the same result. The cool thing about using two's-complement to represent signed integers is that it doesn't have to do anything. The int value -4 and the unsigned int value 4294967292 have exactly the same bit representation. The rules are defined in terms of values, but they're designed so that they can be easily implemented using bitwise operations.)

Similarly, c will have the value -5 + 2³², or 4294967291.

Now you add them together. The mathematical result is 8589934583, but that won't fit in an unsigned int. Using rules similar to those for conversion, the result is reduced to a value that's within the range of unsigned int, yielding 4294967287 (or, in hex, 0xfffffff7).

You also tried a cast:

printf ("result is %u\n",(int)c);

Here you're passing an int argument to printf, but you've told it (by using %u) to expect an unsigned int. You've also tried to convert a value that's too big to fit in an int -- and the unsigned-to-signed conversion rules do not define the result of such a conversion when the value is out of range. So don't do that.