Click here to Skip to main content
Sign Up to vote bad
good
See more: C++C
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

Comments
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

2 solutions

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.
 
Take a look at this link for more information: http://en.wikipedia.org/wiki/Integer_overflow[^]
 
Good luck!
  Permalink  
Comments
Manas Bhardwaj - 16 Aug '12 - 11:10
Correct +5!
CIDev - 16 Aug '12 - 15:37
Nice explanation, +5
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...
  Permalink  
Comments
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!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Your Filters
Interested
Ignored
     
0 Sergey Alexandrovich Kryukov 464
1 Mahesh Bailwal 373
2 Maciej Los 215
3 Rohan Leuva 175
4 CPallini 175
0 Sergey Alexandrovich Kryukov 9,402
1 OriginalGriff 7,204
2 CPallini 3,933
3 Rohan Leuva 3,211
4 Maciej Los 2,743


Advertise | Privacy | Mobile
Web02 | 2.6.130516.1 | Last Updated 16 Aug 2012
Copyright © CodeProject, 1999-2013
All Rights Reserved. Terms of Use
Layout: fixed | fluid