4

I know this question has been partly answered here on S.O., but there they explain what happens during an arithmetic overflow. And elsewhere on S.O. they explain how to check for overflow in java code, i.e. to prevent it as a programmer.

Here I am asking why there are no exceptions at run-time, and no compiler warnings?

AFAIK, this has not been answered before.

In Bruce Eckel's book Thinking in Java, 1st ed. (2000), Chapter 3, there is this little java program:

//: Overflow.java
// Surprise! Java lets you overflow.
public class Overflow {
      public static void main(String[] args) {
        int big = 0x7fffffff; // max int value
        prt("big = " + big);
        int bigger = big * 4;
        prt("bigger = " + bigger);
      }
      static void prt(String s) {
        System.out.println(s);
      }
} ///:~

The output of this is:

big = 2147483647
bigger = -4

and you get no errors or warnings from the compiler, and no exceptions at run-time.

No change when Integer.MAX_VALUE is used instead of "0x7fffffff"

I have tried this on some java compilers from 1.2 to 1.6, and it still shows this behaviour. I now wonder why this is so?

  • Is this a bug or feature?
  • Is this impossible to detect, or a low-priority issue for compiler designers?
  • Is this not fixed because of backward compatibility?
  • Maybe in newer releases of the JDK, can this be controlled at compile time by enabling some rarely used compiler switch/-D:property, or some java VM argument (-XX:...)?

Just now I used these VMs, Windows x86 32 bit

Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)

and

Java(TM) SE Runtime Environment (build 1.7.0_03-b05)
Java HotSpot(TM) Client VM (build 22.1-b02, mixed mode, sharing)

By the way, C# (Microsoft.CSharp\v4.0_4.0.0.0) shows the same behaviour 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OverflowCheck
{
    class Overflow
    {
        static void Main(string[] args)
        {
            int big = 0x7fffffff; // same behaviour vor Int32.MaxValue
            prt("big = " + big);
            int bigger = big * 4;
            prt("bigger = " + bigger);
            prt("done");
        }
          static void prt(String s) {
            System.Console.WriteLine(s);

        }
    }
}

Output:

big = 2147483647
bigger = -4
Community
  • 1
  • 1
knb
  • 9,138
  • 4
  • 58
  • 85
  • In C# the behaviour is configurable, including via the `checked` keyword: see http://msdn.microsoft.com/en-us/library/74b4xzyw(v=vs.71).aspx – Daniel Earwicker Feb 19 '12 at 12:26

3 Answers3

4

The language specification mandates wrap-around behaviour for overflowing computations, so it's a feature. Since most overflows cannot be detected at compile time, it's of dubious value to check for those that can be detected, in particular because they may have been intentional.

Daniel Fischer
  • 181,706
  • 17
  • 308
  • 431
  • Maybe it might still be of some value for the realm of scientific computing? Someone might add such an optional warning as, say, part of the "pedantic" level of compilation warnings. – knb Feb 19 '12 at 11:10
  • Some value, yes, but limited. The compiler can't find all places of possible overflow anyway, so even a warning-free compilation still requires you to check in your code if you mustn't have overflow. So if it's important to avoid overflow, you have to check yourself or use a type that doesn't overflow/triggers exceptions when it would - `BigInteger` can handle everything you'd normally need and some beyond, and I think throws an exception when it would overflow (I know the GMP types call `abort()` when trying to allocate a too big value). – Daniel Fischer Feb 19 '12 at 11:26
2

This is specified in the java language specification: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.2

The built-in integer operators do not indicate overflow or underflow in any way.

Also, almost all languages will behave this way by using wrap-around overflow instead of throwing an overflow error. Why? Partly because historically it has been this way, and because it is easier if you look at integer arithmetic as a purely binary operation.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
  • 1
    +1 for the link to the spec. Regarding the "almost all languages will behave this way", it's worth to point out two important examples, C and C++, for which overflow of _signed_ integers is undefined behaviour, so you can't count on them behaving that way (and they sometimes don't; gcc has an `-fwrapv` flag that forces that behaviour, however). Unsigned integers are required to use wrapping/modulo behaviour, though. – Daniel Fischer Feb 19 '12 at 11:16
1

It's probably due to performance concerns.

For large amount of data, verifying numeric range correctness might cause a significant slowdown.

Community
  • 1
  • 1
Adam Matan
  • 128,757
  • 147
  • 397
  • 562