See more:
```unsigned int i=65535;
int j;
j=i;
printf("%d",j);
output

-1   //// Why the output of j=-1 ....Please explain this

int j=-2;
unsigned int i=1+j;
printf("%u",i);
output

65535   //// Wht the output of i=65535```
Posted 16 Aug '12 - 4:49

Wes Aday - 16 Aug '12 - 10:56
The concept you are looking for here is "overflow".
enhzflep - 16 Aug '12 - 11:00
Because you're using a 16bit compiler (TurboC?) and are treating signed and unsigned ints interchangeably. The bits are the same, it's a matter of interpretation. Assuming 16Bit, -1 = 0xFFFF as does 65535 = 0xFFFF

## Solution 1

Both comments are right I just wanted to add some extra resources and a little bit more of comments:

Any variable has a maximum and a minimum allowed. See this table: http://msdn.microsoft.com/en-us/library/296az74e.aspx[^].

If a variable can go from -32768 to 32767, and you are putting inside the variable a value out of bounds, then you will have an overflow and it is handled depending on the case, at the very end, a number is an amount of bits and a representation (sign must be represented) so depending on the kind of container you are using some bits can mean one thing or another one.

Good luck!
Manas Bhardwaj - 16 Aug '12 - 11:10
Correct +5!
CIDev - 16 Aug '12 - 15:37
Nice explanation, +5

## Solution 2

This is not really overflow, you can simply treat an N bit integer as signed and unsigned. If you use the integer as signed then the N bit integer can store values in the range [-2^(N-1) .. 2^(N-1)-1] if you use it as unsigned then it value range is [0 .. (2^N)-1]. No matter which way you use that integer, range [0 .. 2^(N-1)-1] is the same in both cases.
Read this article to understand what I mean, the same integer value and its bits can be interpreted as either a signed or an unsigned integer:
http://en.wikipedia.org/wiki/Two%27s_complement[^]

also try this:
```int i;
unsigned int ui;
for (i=-5; i<=5; ++i)
{
ui = (unsigned int)i;
printf("%2d %2d %2u %2u %04x %04x\n", i, ui, i, ui, i, ui);
}
```
After running this piece of code you will see that the hex value (binary representation) of i and ui are always the same, only the printf function and the generated assembly code treats the bits of the integer differently.

EDIT:
Try this code as well:
```int i;
for (i=0; i<256; ++i)
{
printf("%d%d%d%d%d%d%d%d %02x %3u %4d\n", i&0x80?1:0, i&0x40?1:0, i&0x20?1:0, i&0x10?1:0,
i&0x8?1:0, i&0x4?1:0, i&0x2?1:0, i&0x1?1:0, i, (unsigned char)i, (signed char)i);
}
```
This piece of code prints byte values from 0x00 to 0xFF and it always prints you which decimal value do you get if you interpret those bits as unsigned and signed values. Check out the negative numbers! where is the highest and the lowest negative number? what happens if you subtract 1 from an integer whose value is currently 0 and you print it as a binary, signed or unsigned format? This is where the topic of overflow comes in...
nv3 - 16 Aug '12 - 14:30
You are right. This has nothing to do with overflow; we didn't even perform an operation on j. It's simply a matter of how to interpret a 16-bit pattern. We could even interpret it as a floating point number (if such a small float type would be around) and would even receive a third value. Got my 5. A tiny glitch: In your comments you are assuming 2's complement arithmetic, which is true for most processors today, but not guaranteed. There are still a couple of processors around that do 1's complement and in which the equivalent of 0xFFFF is not -1 but -0, and -1 is represented 0xFFFE.
pasztorpisti - 16 Aug '12 - 14:39
Thank you! Didn't know that some processors use 1's complement, why is that good? Anyway, there is 16 bit float type, widely used by graphics accelerators: http://en.wikipedia.org/wiki/Half-precision_floating-point_format :-)
Sergey Alexandrovich Kryukov - 16 Aug '12 - 16:31
Very good, my 5. I don't think presentations other then 2's complements are really considerable, but I also faced at least one case of hardware using something else, very dense one :-). --SA
pasztorpisti - 16 Aug '12 - 17:00
Thank you!