3

I'm on Visual Studio 2019, and when I try to compile this:

#include <iostream>

int main() {
    (-2147483647 - 1) / -1;
    INT_MIN / -1;
}

I get a compiler error in both cases:

C2124 'divide or mod by zero'

There's no divide or mod by zero as far as I can see.

Casey
  • 10,297
  • 11
  • 59
  • 88
Zebrafish
  • 11,682
  • 3
  • 43
  • 119
  • 2
    The problem is that `-INT_MIN` is outside the range of `INT_MAX`. That's a consequence of two's complement arithmetic. – Mark Ransom Mar 09 '21 at 15:56
  • 1
    It is common for compilers and runtimes to report an overflow during a division as a divide by zero error, which is at least partly because at the hardware level you often have the same exception for both. – 1201ProgramAlarm Mar 09 '21 at 16:19

2 Answers2

2

By turning the warning level up the compiler reveals the root cause:

main.cpp(4,23): warning C4427: '/': overflow in constant division, undefined behavior
main.cpp(5,13): warning C4427: '/': overflow in constant division, undefined behavior
main.cpp(4,1): error C2124: divide or mod by zero

You have UB which MSVC has decided to handle by overflowing to zero. Because the new values are zero, then the division is performed, the compiler complains about division by zero.

When coding, have your warnings set as high as Level 4 with Treat Warnings As Errors turned on. This way you are forced to fix your warnings. Most likely the first warning is the cause of all the other problems afterwards. By being forced to fix the first warning in the list you potentially fix most or all of the other problems.

Casey
  • 10,297
  • 11
  • 59
  • 88
  • The thing that overflows and that you said MSVC is probably handling by overflowing to zero is the part before the divide sign (/)(dividend), it's still being divided by -1 right, not zero. So there is no division by 0? It's just an error in the compiler message? – Zebrafish Mar 09 '21 at 17:13
  • @Zebrafish You are invoking UB. Anything can happen. Googling `c++ invoking UB` provided this SO answer about how a compiler can assume no UB, specifically with what you are doing: signed overflow is UB. https://stackoverflow.com/a/59105709/421178 – Casey Mar 09 '21 at 17:25
  • The explanation is incorrect. Given 32-bit integers with 2s complement encoding, `-2147483647 - 1` doesn't overflow, as this answer suggests. The overflow happens when dividing that value by `-1`, since it can no longer be represented as a 32-bit 2s complement integer. It's unclear how any of that triggers C2114. UB has nothing to do with this; that refers to the virtual abstract machine. Compilers are very real and usually exhibit predictable behavior. – IInspectable Mar 10 '21 at 06:27
  • @IInspectable The explaination may be incorrect right now, but it's UB. So literally any explanation is the correct one. :P The implementer can do whatever it wants. The next version of VS may do something entirely different making even your explanation incorrect. Regardless, invoking UB: "Don't do that". – Casey Mar 10 '21 at 17:47
  • `(INT_MIN + 1) - 1` is well defined for **any** implementation. If you state that this were to exhibit UB, you are wrong. Concluding that being wrong were perfectly fine so long as there is UB *anywhere* is hard to justify. – IInspectable Mar 11 '21 at 10:00
2

Draft n1570 for C11 says at 6.5.5 Multiplicative operators §6 (emphasize mine):

When integers are divided, the result of the / operator is the algebraic quotient with any fractional part discarded. 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.

And we are in the corner case. Let us do the operation forgetting for a while the representation:

-2147483647 - 1 = -2147483648       (1)
-2147483648 / (-1) = 2147483648     (2)

Now we have a system with 32 bits integers in 2-complement. So INT_MAX is 2147483647 and INT_MIN is -2147483648

So (1) is fine and we get INT_MIN that can be represented as a signed int. But (2) gives INT_MAX + 1 which cannot. So the operation seems valid, except that its result cannot be represented by an int. Because of §6, the result is explicitely undefined and any behaviour is legal on a standard point of view. So when MSVC decides to raise a division by 0 error when the actual problem is not that, it is standard conformant.

I often hate Microsoft error messages for not being relevant, but except here integer overflow never raise any error, and the result is silently brought into the [INT_MIN,INT_MAX] by dropping bits over 32. But here you would get x / (-1) == x, while it is the only possible overflow in division. MSVC designers decided that it was really a special case that required to raise an error. They searched for the possible errors raised by a division and only found the division by 0, so they used it.

They could have used a more explicit message, but as the standard allowed any behaviour they just choosed the cheapest way...

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
  • I wouldn't say "cheapest" way. It's more a "Because the Standard Says So"tm a la "You can do anything" so they just threw an error that already existed and called it good. It's better than "anything" being interpreted as "format your hard drive". – Casey Mar 09 '21 at 17:59