Java is considered to be a safer language than C or C++. The following excerpt is from the introduction of secure coding guidelines from SUN [SUN secure coding|http://java.sun.com/security/seccodeguide.html] :
_"The (java) language is type-safe, and the runtime provides automatic memory management and range-checking on arrays. These features also make Java programs immune to the stack-smashing and buffer overflow attacks possible in the C and C+\+ programming languages, and that have been described as the single most pernicious problem in computer security today"_
While this statement is in fact true, the arithmetic operations in the Java platform require the same caution as in C\C++. Integer operations can result in overflow or underflow since Java does not provide any indication of these conditions and silently wraps (Java throws only a division by zero exception).
\\
See the following example:
h2. Noncompliant Code Example
In we have the following simple method the result could overflow
{code:bgColor=#FFcccc}
public int do_operation(int a,int b)
{
int temp = a + b;
//Could result in overflow
//do other processing
return temp;
}
{code}
\\
If the result of the addition, is greater than the maximum value that the int type can store or less than the minimum value that the int type can store, then the variable temp has a wrong result stored. Although, unlike C\C+\+ the integer overflow is almost impossible to exploit in Java because of the memory properties in this platform (e.g. explicit array bound checking; if temp has a negative value as a result of an overflow and we use it as an array index we get an java.lang.ArrayIndexOutOfBoundsException) the results of our operation are wrong and can lead to undefined or incorrect behavior
All the of the following operators can lead to overflow (same as in C\C++):
\\
\\
\|\| Operator \|\| Overflow \|\| \|\| Operator \|\| Overflow \|\| \|\| Operator \|\| Overflow \|\| \|\| Operator \|\| Overflow \|\|
\\
\| + \| yes \| \| \-= \| yes \| \| << \| yes \| \| < \| no \|
| - | yes | | \*= | yes | | >> | no | | > | no |
| * | yes | | /= | yes | | & | no | | >= | no |
| / | yes | | %= | yes | | \| | no | | <= | no |
| % | yes | | <<= | yes | | ^ | no | | == | no |
| \+\+ | yes | | >>= | no | | ~ | no | | \!= | no |
| \-\- | yes | | &= | no | | \! | no | | && | no |
| = | no | | \|= | no | | un\+ | no | | \|\| | no |
| \+= | yes | | \^= | no | | un\- | yes | | ?: | no | |
\\
h1. Addition
Addition (and all operations) in Java as performed in signed numbers as Java does not support unsigned numbers
\\
h2. Compliant Solution (Bounds Checking)
\\
A solution would be to explicitly check the range of each arithmetic operation and throw an ArithmeticException on overflow, otherwise downcast the value to an integer. For arithmetical operations on really big numbers one should always use the BigInteger Class
In this platform according to SUN [Java Data Types|http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html]:
\\
_ _ _\-the integer_ _data type is a 32-bit signed two's complement integer. It has a minimum value of \-2,147,483,648 and a maximum value of 2,147,483,647 (inclusive)._
_ _ _\- the long data type is a 64-bit signed two's complement integer. It has a minimum value of \-9,223,372,036,854,775,808 and a maximum value of 9,223,372,036,854,775,807 (inclusive). Use this data type when you need a range of values wider than those provided by_ int
\\
So since long is guaranteed to be able to hold the result of an int addition, we could assign the result to a long and if the result is in the integer range we simply downcast. All of the tests would be the same as with signed integers in C since Java does not support unsigned numbers
e.g for the previous example
\\
{code:bgColor=#ccccff}
public int do_operation(int a, int b) throws ArithmeticException
{
long temp = (long)a+(long)b;
if(temp >Integer.MAX_VALUE || temp < Integer.MIN_VALUE) throw ArithmeticException;
else //Value within range can perform the addition
//Do stuff
return (int)temp;
}
{code}\\
Another example would be of explicit range checking would be:
\\
public int do_operation(int a, int b) throws ArithmeticException
\\
{ long temp = (long)a+(long)b; if(a>0 && b>0 && (a >Integer.MAX_VALUE - b) || a<0 && b<0 && (a < Integer.MIN_VALUE -b)) throw ArithmeticException; else //Value within range can perform the addition //Do stuff return (int)temp; }
Another compliant approach would be to use the BigInteger class in this example and in the examples of the other operations using a wrapper for test of the overflow:
\\
\\
public bool overflow(int a, int b)
{ java.math.BigInteger ba = new java.math.BigInteger(String.valueOf(a)); java.math.BigInteger bb = new java.math.BigInteger(String.valueOf(b)); java.math.BigInteger br = ba.add(bb); if(br.compareTo(java.math.BigInteger.valueOf(Integer.MAX_VALUE)) == 1 || br.compareTo(java.math.BigInteger.valueOf(Integer.MIN_VALUE))== -1) return true;//We have overflow //Can proceed return false }
public int do_operation(int a, int b) throws ArithmeticException
{ if overflow(a,b) throw ArithmeticException; else //we are within range safeley perform the addition }\\
By using the BigInteger class there is no chance to overflow (see section on BigInteger class) *{_}but the performance is degraded so it should be used only on really large operations{_}*
\\
\\
\\
\\
\\
h1. Subtraction
\\
Care must be taken in subtraction operations as well as these can overflow as well.
\\
h2. Compliant Code Example
\\
int a,b,result;
long temp = (long)a-(long)b;
if(long < Integer.MIN_VALUE \|\| long > Integer.MAX_VALUE)
throw ArithmeticException;
else
result = (int) temp;
\\
\\
\\
\\
h1. Multiplication
\\
This noncompliant code example, can result in a signed integer overflow during the multiplication of the signed operands a and b. If this behaviour is unanticipated, the resulting value may lead to undefined behaviour
\\
h2. Noncompliant Code Example
\\
int a,b,result
//do stuff
result = a*b;//May result in overflow
\\
\\
\\
h2. Compliant Code Example
Since in this platform the size of type long (64 bits) is twice the size of type int (32 bits) we should perform the multiplication in terms of long and if the product is in the integer range we downcast the result to int
\\
int a,b,result;
long temp = (long) a\* (long)b;
if(temp > Integer.MAX_VALUE \|\| temp < Integer.MIN_VALUE)
throw ArithmeticException;//overflow
else
result = (int) temp;//Value within range, safe to downcast
\\
\\
h1. Division
\\
Although Java throws a _java.lang.ArithmeticException: / by zero exception_ for division by zero, there is the same issue as in C\C+\+ when dividing the Integer.MIN_VALUE with \-1. It produces Integer.MIN_VALUE unexpectedly
(since the result is \-(Integer.MIN_VALUE)=Integer.MAX_VALUE \+1))
\\
A non-compliant example is:
h2. Noncompliant Code Example
\\
int a,b,result
result = a/b;
\\
\\
h2. Compliant Code Example
\\
if(a == Integer.MIN_VALUE && b == \-1)
throw ArithmeticException;//May be Integer.MIN_VALUE again????
else
result = a/b;//safe operation
\\
\\
\\
h1. Division
\\
\\
For modulo operator the only problem is if we take the modulo of Integer.MIN_VALUE with \-1. The result is always 0 in JAVA so we are back to the previous rule (for division)
\\
h1. Unary Negation
\\
If we negate Integer.MIN_VALUE we get Integer.MIN_VALUE. So we explicitely check the range
\\
\\
if(a == Integer.MIN_VALUE)
throw ArithmeticException;
else
result = \-a;
h1. Operations Requiring Really Long Numbers
\\
For these operations the BigInteger class should be used. According to SUN [BigInteger Class|http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigInteger.html]:
_"Semantics of arithmetic operations exactly mimic those of Java's integer arithmetic operators, as defined in The Java Language Specification. For example, division by zero throws an_ {{{_}ArithmeticException{_}{}}}_, and division of a negative by a positive yields a negative (or zero) remainder. All of the details in the Spec concerning overflow are ignored, as BigIntegers are made as large as necessary to accommodate the results of an operation."_
So operations using BigInteger class are guaranteed not to overflow regardless of the size of the result.
For instance operations on long are operations on 64 bits. For example addition:
h2. Compliant Code Example
\\
java.math.BigInteger big_long_max = new java.math.BigInteger(String.valueOf(Long.MAX_VALUE));
System.out.println("big_long="+big_long_max);
big_long_max = big_long_max.add(java.math.BigInteger.valueOf(1));//same as \++big_long_max
System.out.println("big_long="+big_long_max);
These print
big_long=9223372036854775807
big_long=9223372036854775808//exceeds the maximum range of long, no problem\!
java.math.BigInteger big_long_min = new java.math.BigInteger(String.valueOf(Long.MIN_VALUE));
System.out.println("big_long_min="+big_long_min);
big_long_min = big_long_min.subtract(java.math.BigInteger.valueOf(1));//same as \--big_long_min
System.out.println("big_long_min="+big_long_min);//goes bellow minimum range of long, no problem\!
These print:
big_long_min=-9223372036854775808
big_long_min=-9223372036854775809
if(big_long < Long.MAX_VALUE && big_long > Long.MIN_VALUE)//value within range can go to the primitive type
long value = big_log.longValue();//get primitive type
else
//Perform error handling. We can not downcast since the value can not be represented as a longWe can always go back to the primitive types if the BigInteger of course can be represented by the type
In the example if big_long is within long range (big_long < Long.MAX_VALUE && big_long > Long.MIN_VALUE) we can use the BigInteger method longValue() to get the long value and assign it to a variable of type long
\\
\\ | 