If I execute the following code in C:
It correctly prints '-4000' as the result. However, I'm a little confused: shouldn't there be an arithmetic overflow when subtracting the larger unsigned integer from the other? What casting rules are at play here? This question seems a bit noobish, so any references would be greatly appreciated.Code:#include <stdint.h> uint16_t a = 4000; uint16_t b = 8000; int32_t c = a - b; printf("%d", c);
Underflow DID happen, but data is what you define it to be. The result, if interpreted as an unsigned type, would be a big number. If interpreted as a signed type, it would be -4000. A beautiful feature of two's complement system is that adding and subtracting are the same for signed/unsigned in terms of bits in and bits out. The only difference would be in zero-extension vs sign-extension.
You are storing it into a 32-bit signed type, so it is sign-extended to 32-bits, and that of course will give you -4000.
You do get an overflow (or rather, underflow, as the second number is greater than the first), but the representation of signed and unsigned is [1] handled by the same instruction, and the only time there is a difference is when converting the number to a string (e.g. printing it) and when dealing with comparative (<, >, >=, <=) operators. All other times, the number is just a set of bits that is operated on with the exact same rules, whether it is signed or unsigned.
[1]in nearly all processors, but I'm sure if I say it categorically IS so, someone will dig out the 1973 manual of XYZ Corp. and tell me that their 17-bit 93188 processor DOES NOT behave this (product entirely made up).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Ah, I see. So if I want to be able to perform this operation without the possibility of an underflow, I would have to typecast both integers to the larger result type first? e.g.:Originally Posted by cyberfish
Code:uint16_t a = 4000; uint16_t b = 8000; int32_t c = (int32_t)a - (int32_t)b;
That is still underflow, technically speaking, as you are subtracting a larger number from a smaller one - underflow is how you get negative numbers from positive ones!
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Alright
I understand that on a 2's complement machine, the operation still technically produces an underflow, but I can assume that this pattern will produce the correct result in all cases (on an i386/686 architecture)?
Note: I'm fairly sure this isn't necessary on 32-bit machines at all because of C's integer promotion rules (ints are 32 bits wide, and therefore most operands are promoted to 32 bits anyway according to the C standard), but if we scale up to a 32/32/64 bit example, the behaviour is not quite so clear-cut. I'm asking about the general case.
