The term arithmetic overflow or simply overflow has the following meanings.

1. In a computer, the condition that occurs when a calculation produces a result that is
greater in magnitude than that which a given register or storage location can store or
represent.
2. In a computer, the amount by which a calculated value is greater in magnitude than that
which a given register or storage location can store or represent. Note that the overflow
may be placed at another location.

Most computers distinguish between two kinds of overflow conditions. A carry occurs when the
result of an addition or subtraction, considering the operands and result as unsigned numbers,
does not fit in the result. Therefore, it is useful to check the carry flag after adding or subtracting
numbers that are interpreted as unsigned values. An overflow proper occurs when the result does
not have the sign that one would predict from the signs of the operands (e.g. a negative result
when adding two positive numbers). Therefore, it is useful to check the overflow flag after
adding or subtracting numbers that are represented in two's complement form (i.e. they are
considered signed numbers).

There are several methods of handling overflow:

1. Design: by selecting correct data types, both length and signed/unsigned.

2. Avoidance: by carefully ordering operations and checking operands in advance, it is
possible to ensure that the result will never be larger than can be stored.
3. Handling: If it is anticipated that overflow may occur and when it happens detected and
other processing done. Example: it is possible to add two numbers each two bytes wide
using just a byte addition in steps: first add the low bytes then add the high bytes, but if it
is necessary to carry out of the low bytes this is arithmetic overflow of the byte addition
and it necessary to detect and increment the sum of the high bytes. CPUs generally have a
way of detecting this to support addition of numbers larger than their register size,
typically using a status bit.
4. Propagation: if a value is too large to be stored it can be assigned a special value
indicating that overflow has occurred and then have all successive operation return this
flag value. This is useful so that the problem can be checked for once at the end of a long
calculation rather than after each step. This is often supported in Floating Point Hardware
called FPUs.
5. Ignoring: This is the most common approach, but it gives incorrect results and can
compromise a program's security.

Division by zero is not a form of arithmetic overflow. Mathematically, division by zero within
reals is explicitly undefined if the problem is zero divided by zero, and is defined as either
positive or negative infinity depending on the signs of the numbers involved, or is undefined.

Arithmetic overflow is a fairly common cause of software failures. Such overflow bugs may be
hard to discover and diagnose because they may manifest themselves only for very large input
data sets, which are less likely to be used in validation tests.[1]
================================================================
The CARRY flag and OVERFLOW flag in binary arithmetic

- Ian! D. Allen - idallen@idallen.ca - www.idallen.com

Do not confuse the "carry" flag with the "overflow" flag in integer arithmetic. Each flag can
occur on its own, or both together. The CPU's ALU doesn't care or know whether you are doing
signed or unsigned mathematics; the ALU always sets both flags appropriately when doing any
integer math. The ALU doesn't know about signed/unsigned; the ALU just does the binary math
and sets the flags appropriately. It's up to you, the programmer, to know which flag to check
after the math is done.

If your program treats the bits in a word as unsigned numbers, you must watch to see if your
arithmetic sets the carry flag on, indicating the result is wrong. You don't care about the
overflow flag when doing unsigned math. (The overflow flag is only relevant to signed
numbers, not unsigned.)

If your program treats the bits in a word as two's complement signed values, you must watch to
see if your arithmetic sets the overflow flag on, indicating the result is wrong. You don't care
about the carry flag when doing signed, two's complement math. (The carry flag is only relevant
to unsigned numbers, not signed.)

In unsigned arithmetic, watch the carry flag to detect errors.

In unsigned arithmetic, the overflow flag tells you nothing interesting.

In signed arithmetic, watch the overflow flag to detect errors.

In signed arithmetic, the carry flag tells you nothing interesting.

Carry Flag

The rules for turning on the carry flag in binary/integer math are two:

1. The carry flag is set if the addition of two numbers causes a carry out of the most significant
(leftmost) bits added.

1111 + 0001 = 0000 (carry flag is turned on)

2. The carry (borrow) flag is also set if the subtraction of two numbers requires a borrow into the
most significant (leftmost) bits subtracted.

0000 - 0001 = 1111 (carry flag is turned on)

Otherwise, the carry flag is turned off (zero).

* 0111 + 0001 = 1000 (carry flag is turned off [zero])
* 1000 - 0001 = 0111 (carry flag is turned off [zero])
In unsigned arithmetic, watch the carry flag to detect errors.
In signed arithmetic, the carry flag tells you nothing interesting.

Overflow Flag

The rules for turning on the overflow flag in binary/integer math are two:

1. If the sum of two numbers with the sign bits off yields a result number with the sign bit on, the
"overflow" flag is turned on.

0100 + 0100 = 1000 (overflow flag is turned on)

2. If the sum of two numbers with the sign bits on yields a result number with the sign bit off, the
"overflow" flag is turned on.

1000 + 1000 = 0000 (overflow flag is turned on)

Otherwise, the overflow flag is turned off.

* 0100 + 0001 = 0101 (overflow flag is turned off)
* 0110 + 1001 = 1111 (overflow flag is turned off)
* 1000 + 0001 = 1001 (overflow flag is turned off)
* 1100 + 1100 = 1000 (overflow flag is turned off)

Note that you only need to look at the sign bits (leftmost) of the three numbers to decide if the
overflow flag is turned on or off.

If you are doing two's complement (signed) arithmetic, overflow flag on means the answer is
wrong - you added two positive numbers and got a negative, or you added two negative numbers
and got a positive.

If you are doing unsigned arithmetic, the overflow flag means nothing and should be ignored.

The rules for two's complement detect errors by examining the sign of the result.

A negative and positive added together cannot be wrong, because the sum is between the
addends. Since both of the addends fit within the allowable range of numbers, and their sum is
between them, it must fit as well. Mixed-sign addition never turns on the overflow flag.

In signed arithmetic, watch the overflow flag to detect errors.

In unsigned arithmetic, the overflow flag tells you nothing interesting.
How the ALU calculates the Overflow Flag
----------------------------------------

This material is optional reading.

There are several automated ways of detecting overflow errors in two's complement binary
arithmetic (for those of you who don't like the manual inspection method). Here are two:

Calculating Overflow Flag: Method 1

-----------------------------------

Overflow can only happen when adding two numbers of the same sign and getting a different
sign. So, to detect overflow we don't care about any bits except the sign bits. Ignore the other
bits.

With two operands and one result, we have three sign bits (each 1 or 0) to consider, so we have
exactly 2**3=8 possible combinations of the three bits. Only two of those 8 possible cases are
considered for overflow. Below are just the sign bits of the two addition operands and result:

ADDITION SIGN BITS

num1sign num2sign sumsign

---------------------------------------------------------------------------------------------------------------------
0 0 0
*OVER* 0 0 1 (adding two positives should be positive)
0 1 0
0 1 1
1 0 0
1 0 1
*OVER* 1 1 0 (adding two negatives should be negative)
1 1 1

We can repeat the same table for subtraction. Note that subtracting a positive number is the
same as adding a negative, so the conditions that trigger the overflow flag are:

SUBTRACTION SIGN BITS

num1sign num2sign sumsign

--------------------------------------------------------------------------------------------------------------------
0 0 0
0 0 1
0 1 0
*OVER* 0 1 1 (subtracting a negative is the same as adding a
positive)
*OVER* 1 0 0 (subtracting a positive is the same as adding a
negative)
 1 0 1
1 1 0
1 1 1

A computer might contain a small logic gate array that sets the overflow flag to "1" iff any one of
the above four OV conditions is met.

A human need only remember that, when doing signed math, adding two numbers of the same
sign must produce a result of the same sign, otherwise overflow happened.

Calculating Overflow Flag: Method 2

-----------------------------------------------

When adding two binary values, consider the binary carry coming into the leftmost place (into
the sign bit) and the binary carry going out of that leftmost place. (Carry going out of the
leftmost [sign] bit becomes the CARRY flag in the ALU.)

Overflow in two's complement may occur, not when a bit is carried out out of the left column,
but when one is carried into it and no matching carry out occurs. That is, overflow happens when
there is a carry into the sign bit but no carry out of the sign bit.

The OVERFLOW flag is the XOR of the carry coming into the sign bit (if any) with the carry
going out of the sign bit (if any). Overflow happens if the carry in does not equal the carry out.

Examples (2-bit signed 2's complement binary numbers):

11
+01
===
00

- carry in is 1
- carry out is 1
- 1 XOR 1 = NO OVERFLOW

01
+01
===
10

- carry in is 1
- carry out is 0
- 1 XOR 0 = OVERFLOW!
 11
+10
===
01

- carry in is 0
- carry out is 1
- 0 XOR 1 = OVERFLOW!

10
+01
===
11

- carry in is 0
- carry out is 0
- 0 XOR 0 = NO OVERFLOW

Note that this XOR method only works with the *binary* carry that goes into the sign *bit*. If
you are working with hexadecimal numbers, or decimal numbers, or octal numbers, you also
have carry; but, the carry doesn't go into the sign *bit* and you can't XOR that non-binary carry
with the outgoing carry.

Hexadecimal addition example (showing that XOR doesn't work for hex carry):

8Ah
+8Ah
====
14h

The hexadecimal carry of 1 resulting from A+A does not affect the sign bit. If you do the math
in binary, you'll see that there is *no* carry *into* the sign bit; but, there is carry out of the sign
bit. Therefore, the above example sets OVERFLOW on. (The example adds two negative
numbers and gets a positive number.)

--
| Ian! D. Allen - idallen@idallen.ca - Ottawa, Ontario, Canada
| Home Page: http://idallen.com/ Contact Improv: http://contactimprov.ca/
| College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/
| Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/
 Real life scenarios of overflow and its consequences

 Integer errors

o There is a Facebook group called “If this group reaches 4,294,967,296 it might
cause an integer overflow. “ This value is the largest number that can fit in a 32
bit unsigned integer. If the number of members of the group exceeded this
number, it might cause an overflow. Whether it will cause an overflow or not
depends upon how Facebook is implemented and which language is used – they
might use data types that can hold larger numbers. In any case, the chances of an
overflow seem remote, as roughly 2/3 of the people on earth would be required to
reach the goal of more than 4 billion members.
o
o On December 25, 2004, Comair airlines was forced to ground 1,100 flights after
its flight crew scheduling software crashed. The software used a 16-bit integer
(max 32,768) to store the number of crew changes. That number was exceeded
due to bad weather that month which led to numerous crew reassignments.
o
o Many Unix operating systems store time values in 32-bit signed (positive or
negative) integers, counting the number of seconds since midnight on January 1,
1970. On Tuesday, January 19, 2038, this value will overflow, becoming a
negative number. Although the impact of this problem in 2038 is not yet known,
there are concerns that software that projects out to future dates – including tools
for mortgage payment and retirement fund distribution – might face problems
long before then. Source: Year 2038 Problem”
http://en.wikipedia.org/wiki/Year_2038_problem

o An unhandled arithmetic overflow in the engine steering software was the

primary cause of the crash of the maiden flight of the Ariane 5 rocket. The
software had been considered bug-free since it had been used in many previous
flights; but those used smaller rockets which generated smaller accelerations than
Ariane 5's.

 Input validation

o In December 2005, a Japanese securities trader made a $1 billion typing

error, when he mistakenly sold 600,000 shares of stock at 1 yen each
instead of selling one share for 600,000 yen. A few lines of code may have
averted this error. Fat fingered typing costs a trader’s bosses £128m, The
Times Online, December 09, 2005
 o Web applications are highly vulnerable to input validation errors.
Inputting the invalid entry “!@#$%^&*()” on a vulnerable e-commerce
site may cause performance issues or denial of service on a vulnerable
system or invalid passwords such as “pwd’” or “1=1— ” may result in
unauthorized access.
http://www.processor.com/editorial/article.asp?article=articles%2Fp3112
%2F32p12%2F32p12%2F32p12.asp&guid=&searchtype=&WordList=&b
JumpTo=True

o A Norwegian woman mistyped her account number on an internet banking

system. Instead of typing her 11-digit account number, she accidentally
typed an extra digit, for a total of 12 numbers. The system discarded the
extra digit, and transferred $100,000 to the (incorrect) account. A simple
dialog box informing her that she had typed too many digits would have
helped avoid this expensive error. Olsen, Kai. “The $100,000 Keying
error” IEEE Computer, August 2008

o The site xssed.com lists nearly 13,000 vulnerable Web pages, including
sites such as yahoo.com, google.com, msn.com, facebook.com,
craigslist.com and cnn.com

o The Risks digest (http://catless.ncl.ac.uk/Risks ) – an invaluable resource

on computing systems gone wrong – carried a report of an electronic
commerce web site that failed to verify the quantity of items ordered.
After accidentally typing “1.1” for the desired quantity of an item (instead
of one), an amused customer found that the system would let him order
1.1 cocktail shakers at $9.99 each, for a total of $10.99. A simple check to
verify that the quantity was an integer value would have eliminated the
absurd possibility of ordering one-tenth of a cocktail shaker.Source:
Richard Kaszeta, “Lack of sanity checking in Web shopping cart software
“ Risks Digest, 23(51) http://catless.ncl.ac.uk/Risks/23.51.html#subj11

o The sinking of the Sleipner A offshore platform in Gands of jorden near

Stavanger, Norway, on August 23, 1991, resulted in a loss of nearly one billion
dollars. It was found to be the result of inaccurate finite element analysis.
o
o The Patriot Missile failure, in Dharan, Saudi Arabia, on February 25, 1991 which
resulted in 28 deaths, is ultimately attributable to poor handling of rounding
errors.