# Wednesday, July 31, 2002
« No Title | Main | No Title »
What's wrong with this picture?
class DivTest
 public static void Main()
  int i = int.MinValue;
  System.Console.WriteLine(i * -1);
  System.Console.WriteLine(i / -1);

Why does div throw an OverflowException when you're trying to divide MinInt by -1? I'm assuming that since dividing by zero throws a DivideByZeroException, the CLR designers thought it would be nice if div would throw an exception for overflow as well.

This sucks!

Partition III CIL.doc section 3.31 about div says:


Integral operations throw ArithmeticException if the result cannot be represented in the result type. This can happen if value1 is the maximum negative value, and value2 is -1.

Integral operations throw DivideByZeroException if value2 is zero.

Implementation Specific (Microsoft)

On the x86 an OverflowException is thrown when computing (minint div –1).

Why didn't they define a div.ovf (like there are add.ovf, sub.ovf, mul.ovf, etc.) in addition to div (and then make div behave consistently with add, submul)?

Question: What should I do? Implement Java's idiv bytecode using this broken div or compile them into conditional code that checks for MinInt / -1 and treats that specially (and thus slowing down integer division).

BTW, J# uses div but I'm not sure they actually thought about this issue. The following code crashes the J# compiler:

 System.out.println(Integer.MIN_VALUE / - 1);
Wednesday, July 31, 2002 4:14:23 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [2]
Wednesday, July 31, 2002 10:53:49 AM (W. Europe Daylight Time, UTC+02:00)

I believe the reason the CLR throws an exception
in this case is that the div CIL opcode is compiled
down to the idiv x86 opcode, which raises a hardware exception in case of overflow. A div
opcode which does not throw an exception would be
much slower, since it would have to be implemented
by a series of x86 opcodes.
Zoltan Varga
Wednesday, July 31, 2002 12:11:16 PM (W. Europe Daylight Time, UTC+02:00)

Horrible hacky proposed solution: implement idiv using the broken div, but add an exception handler to every java method that uses idiv that tests for the pathological case and somehow resumes in the right place.

Or just wrap map java (x/y) to try{x/y} catch(OverflowException e) {x}. How much execution overhead is there for a try-catch in the non-exception case?

Comments are closed.