Output: -2147483648Code:#include <stdio.h>
#include <math.h>
int main()
{
int i = 1073741824ul;
int total = i + i;
printf("%d", total);
return 0;
}
The real answer is suppose to be: 2147483648
why does C return a negative number?
Printable View
Output: -2147483648Code:#include <stdio.h>
#include <math.h>
int main()
{
int i = 1073741824ul;
int total = i + i;
printf("%d", total);
return 0;
}
The real answer is suppose to be: 2147483648
why does C return a negative number?
I doubt that the real answer is supposed to be 2147483648, since that is not a valid int on any system I'm aware of (on my sizeof(int)==4 system, INT_MIN is -2147483648 and INT_MAX is 2147483647). I'm guessing that someone simply dropped a negative sign when they told you what the "right" answer was (or you did, if you did the modular arithmetic yourself).
..."right" meaning arithmetically right...Quote:
Originally Posted by tabstop
In python: 1073741824 * 2 = 2147483647 this is arithmetically correct.
Why does the above C program even compile? Let alone produce that output?
Why wouldn't it compile?
And if you want a "ul" number, why not make i "unsigned long i" instead of "int i"? Also note that you don't print unsigned numbers with %d, but with %u (%lu for unsigned long).
Since this hasn't been answered yet. It's due to wraparound. When an variable in C gets larger than the maximum +ve value it can hold, you will overflow into the sign bit and set it. When the sign bit is set, the number is considered -ve and hence you see a -ve answer. You won't have that problem if you a) use a bigger variable like a long long b) in this case if you make the total unsigned.Quote:
Originally Posted by brooksbp
QuantumPete
Technically
Should yield the desired result despite the fact i would still hold a negative value.Code:#include <stdio.h>
#include <math.h>
int main()
{
int i = 1073741824ul;
int total = i + i;
printf("%u", total);
return 0;
}
[edit]If something does not compile, typically your compiler throws back some sort of error or a vast list of warnings that it deemed fatal enough to not compile your code. Consult those.[/edit]
No it isn't. A simple logic check would tell ya that 4 * 2 isn't going to give you 7, or even more basic that an even * even isn't going to give you an odd.Quote:
Originally Posted by brooksbp
The whole thing boils down to what the range of the storage is and what their overflow behavior is. C says that signed integer overflow is undefined. On your system a signed int is too small to hold that value.
Because C has made the "choice" of mapping closely to the computer hardware. In the lowest level of your computer, the CPU performs "wraparound" (as mentioned above) when values don't fit in its registers. A computer language could take this into account (specifically if it targeted a virtual machine, as do Java or the .NET languages), but this is at a (significant) performance penalty.Quote:
Originally Posted by brooksbp
When using MMX/SSE instructions, x86 CPUs also have a "saturation" mode in arithmetic (i.e. when the result of a value would be larger than the maximum value representable by the type, it would clip to that maximum value). This is really nice for certain types of calculations (in image processing, for instance). However, C does not offer a mapping to this mode.
Computer Programming: An Introduction for the Scientifically Inclined