9

Can (true) integer division ever over/underflow (with the assumption that the denominator is not 0)?

Since the value is always either staying the same or getting smaller (since, in integer division, the smallest absolute non-zero denominator is 1, therefore the result can never be bigger than the numerator), I would assume not.

I'm asking more or less in the context of C/C++ standards, and I'm interested in how the various modern CPU architectures might handle integer division differently when it comes to defined/undefined behavior.

Jim Rhodes
  • 5,021
  • 4
  • 25
  • 38
Qix - MONICA WAS MISTREATED
  • 14,451
  • 16
  • 82
  • 145

1 Answers1

11

Since the value is always either staying the same or getting smaller...

That's what I used to think, too, but when we say that, we're quietly assuming the denominator is positive.

And since the denominator can be negative, there's one obscure but ruinous case: under 2's complement arithmetic, the mathematical result of INT_MIN / -1 is a number that's one more than INT_MAX.

That is, on a 16-bit 2's complement machine, INT_MIN is −32768 which is perfectly representable, but −32768 ÷ −1 wants to be +32768, but INT_MAX is just 32767. Similarly, in 32 bits, −2147483648 is representable but can't be divided by −1, either.

This is a peculiar quirk of 2's complement arithmetic, arising because the magnitude of INT_MIN is not quite the same as INT_MAX. Under one's complement or sign/magnitude arithmetic, on the other hand, INT_MIN is exactly the negative of INT_MAX, so there's no "ruinous case", and as far as I know division is well defined for all inputs (well, except for zero in the denominator, of course).

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
  • 1
    hmmmm ... there's no such thing as "one more than `INT_MAX`" :) – pmg Nov 15 '19 at 17:10
  • 3
    @pmg yes, but it "wants to be" ;) – Patrick Roberts Nov 15 '19 at 17:11
  • 1
    @pmg Smiley noted, but you're right. Wording adjusted. – Steve Summit Nov 15 '19 at 17:12
  • And this is why I still ask such seemingly simple questions. It's obvious now that you pointed it out. Thanks :) – Qix - MONICA WAS MISTREATED Nov 15 '19 at 17:12
  • 1
    Just to make it clear: *"..result of the / operator is the algebraic quotient with any fractional part discarded.105) If the quotient a/b is **representable**, the expression (a/b)*b + a%b shall equal a; otherwise, the behavior of both a/b and a%b is **undefined**."* http://port70.net/~nsz/c/c11/n1570.html#6.5.5p6 – Eugene Sh. Nov 15 '19 at 17:13
  • @EugeneSh. in which case would a division be unrepresentable if truncated? That clause never made sense to me (why it would be undefined). – Qix - MONICA WAS MISTREATED Nov 15 '19 at 17:14
  • 1
    @Qix If the result is not fitting in the type - it is not represantable. It is not truncated, it is undefined. – Eugene Sh. Nov 15 '19 at 17:15
  • Ah okay, right - that makes sense. – Qix - MONICA WAS MISTREATED Nov 15 '19 at 17:17
  • If a particular platform implements integral arithmetic using sign and magnitude instead of 2's complement form, this "ruinous case" would no longer apply since `INT_MIN` and `INT_MAX` would have the same magnitude, correct? (I am aware that the vast majority of platforms use 2's complement form, this is just a hypothetical) – Patrick Roberts Nov 15 '19 at 17:22
  • 1
    Interestingly, from the same quote we can conclude that `INT_MIN % -1` is undefined too, even though it should result in `0`. – Eugene Sh. Nov 15 '19 at 17:22
  • @EugeneSh. That *is* interesting -- thanks for pointing that out. (I shall have to keep that in mind next time I update my decimal-to-base-negative-one conversion function. :-) ) – Steve Summit Nov 15 '19 at 17:32
  • @PatrickRoberts I believe that's true. Answer updated. – Steve Summit Nov 15 '19 at 17:33
  • @pmg The wording says there is a "number that's one more than INT_MAX", which is certainly true, and that this number is the *mathematical result* (not the *C result*). That number/result isn't representable in the type `int`. Absolutely nothing wrong with the language being used here. – Kaz Nov 15 '19 at 18:17
  • 2
    @Kaz You're not seeing the wording that pmg commented on. (Check the history.) – Steve Summit Nov 15 '19 at 18:23