# Will a computer attempt to divide by zero?

We all know 0/0 is Undefined and returns an error if I were to put it into a calculator, and if I were to create a program (in C at least) the OS would terminate it when I try to divide by zero.

But what I've been wondering is if the computer even attempts to divide by zero, or does it just have "built in protection", so that when it "sees" 0/0 it returns an error even before attempting to compute it?

• 0/0 is undefined, any other number / 0 is a different kind of error, you seem confusing the two – edc65 Feb 26 '16 at 14:44
• Any number divided by 0 is undefined, mathematically speaking. – ManoDestra Feb 26 '16 at 15:44
• @jwg: "if it did have a value it would be 1" - not necessarily; there are whole branches of mathematics devoted to what the value might be in different circumstances :) – psmears Feb 26 '16 at 17:01
• To clarify the terminology here, 0/0 is called an indeterminate form while x/0 for nonzero x is undefined. A calculation that ends up with 0/0 can often be calculated in a different way to give a real answer, whereas x/0 is essentially meaningless. – Era Feb 26 '16 at 17:48
• @jwg you might be interested in l'hopital's rule then. There are definitely cases where 0/0 does not imply a value of 1. – d0nut Feb 26 '16 at 18:48

The CPU has built in detection. Most instruction set architectures specify that the CPU will trap to an exception handler for integer divide by zero (I don't think it cares if the dividend is zero).

It is possible that the check for a zero divisor happens in parallel in hardware along with the attempt to do the division, however, the detection of the offending condition effectively cancels the division and traps instead, so we can't really tell if some part of it attempted the division or not.

(Hardware often works like that, doing multiple things in parallel and then choosing the appropriate result afterwards because then each of the operations can all get started right away instead of serializing on the choice of appropriate operation.)

The same trap to exception mechanism will also be used when overflow detection is turned on, which you ask for usually by using different add/sub/mul instructions (or a flag on those instructions).

Floating point division also has built in detection for divide by zero, but returns a different value (IEEE 754 specifies NaN) instead of trapping to an exception handler.

Hypothetically speaking, if the CPU omitted any detection for attempt to divide by zero, the problems could include:

• hanging the CPU (e.g. in an inf. loop) — this might happen if the CPU uses an algorithm to divide that stops when the numerator is less than the divisor (in absolute value).  A hang like this would pretty much count as crashing the CPU.
• a (possibly predictable) garbage answer, if the CPU uses a counter to terminate division at the maximum possible number of divide steps (e.g. 31 or 32 on a 32-bit machine).
• @Ankush A "system crash" isn't really something that happens at the CPU level. The most likely behavior of a CPU that did not trap on divide by zero would be that it simply does the division operation, produces some nonsense result and keeps going. Just like when you add two integers that happen to overflow. – Ixrec Feb 26 '16 at 8:00
• For floating point, the choice between "NaN" and "trap" is usually settable by flipping flags in the FPU. – Vatine Feb 26 '16 at 11:45
• @Ankush In case what lxrec said was unclear: as far as the CPU is concerned, there is no such thing as a crash. – user253751 Feb 26 '16 at 12:32
• @Ankush Few situations cause a CPU-level "system crash". In those cases we are talking about things like thermal protection shutdown (overheat protection), triple faults and similar situations. Almost every crash you will encounter in ordinary use, including invalid opcodes, are handled by trapping and recovering in some manner, or simply ignoring the error and continuing execution in a potentially unclean state maybe having set some error flag. – a CVn Feb 26 '16 at 12:41
• If you did not trap divide by zero, the result would be, in programming parlance, "Undefined Behavior." This means the computer may do anything. It may, as Bergi mentions, enter a buggy loop and hang. It may simply output some unspecified series of bits that happened to be what came of their implementation of division logic (remember, a computer does not "divide" in the mathematical sense. It does an operation on two numbers, which is close enough to division that we typically get to simply call it "division".. see also floating point roundoff). – Cort Ammon Feb 26 '16 at 14:43

It depends on the language, on the compiler, on whether you are using integers or floating point numbers, and so on.

For floating point number, most implementations use the IEEE 754 standard, where division by 0 is well defined. 0 / 0 gives a well defined result of NaN (not-a-number), and x / 0 for x ≠ 0 gives either +Infinity or -Infinity, depending on the sign of x.

In languages like C, C++ etc. division by zero invokes undefined behaviour. So according to the language definition, anything can happen. Especially things that you don't want to happen. Like everything working perfectly fine when you write the code and destroying data when your customer uses it. So from the language point of view, don't do this. Some languages guarantee that your application will crash; it's up to them how this is implemented. For those languages, division by zero will crash.

Many processors have some kind of built-in "divide" instruction, which will behave differently depending on the processor. On Intel 32bit and 64 bit processors, the "divide" instructions will crash your application when you try to divide by zero. Other processors may behave differently.

If a compiler detects that a division by zero will happen when you execute some code, and the compiler is nice to its users, it will likely give you a warning, and generate a built-in "divide" instruction so that the behaviour is the same.

• "On Intel 32bit and 64 bit processors, the "divide" instructions will crash your application when you try to divide by zero." Citation needed. CPUs don't have any idea about applications, they execute instructions and (if we include the MMU) enforce memory access limits (unless in ring 0, or equivalent in non-Intel-x86 architectures). That the instruction is part of Application A rather than Application B or Operating System Component C is irrelevant to the CPU; whether the instruction can be Instruction X or use Memory Address Y is relevant. – a CVn Feb 26 '16 at 12:44
• To add to @MichaelKjörling comment: The OS has ways of notfiying the application of this (and other kinds of errors). In the windows world it is the EXCEPTION_INT_DIVIDE_BY_ZERO value in the EXCEPTION_RECORD which will be handled by the (hopefully) installed Structed Exception Handling Handler – user45891 Feb 26 '16 at 15:23
• Sometimes they do things other than guaranteeing that your app will crash. For example, many languages/platforms guarantee that they will throw an exception on division by zero. You can then catch and handle said exception without crashing. – reirab Feb 26 '16 at 19:12
• You can delete the "may" within "Other processors may behave differently": On the PowerPC Platform, the division just produces a zero result on division by zero. Which is much more useful than the panicking behavior of the X86 platform. – cmaster - reinstate monica Feb 27 '16 at 14:00

Seems like you're wondering what would happen if someone made a CPU that doesn't explicitly check for zero before dividing. What would happen depends entirely on the implementation of the division. Without going into details, one kind of implementation would produce a result that has all bits set, e.g. 65535 on a 16-bit CPU. Another might hang up.

But what I've been wondering is if the computer even attempts to divide by zero, or does it just have "built in protection", so that when it "sees" 0/0 it returns an error even before attempting to compute it?

Since x/0 makes no sense, period, computers must always check for division by zero. There's a problem here: Programmers want to compute (a+b)/c without having to bother to check if that calculation even makes sense. The underneath-the-hood response to division by zero by the CPU + number type + operating system + language is to either do something rather drastic (e.g., crash the program) or do something overly benign (e.g., create a value that makes no sense such as the IEEE floating point NaN, a number that is "Not a Number").

In an ordinary setting, a programmer is expected to know whether (a+b)/c makes sense. In this context, there's no reason to check for division by zero. If division by zero does happen, and if the machine language + implementation language + data type + operating system response to this is to make the program crash, that's okay. If the response is to create a value that might eventually pollute every number in the program, that's okay, too.

Neither "something drastic" or "overly benign" is is the right thing to do in the world of high reliability computing. Those default responses might kill a patient, crash an airliner, or make a bomb explode in the wrong place. In a high reliability environment, a programmer who writes (a+b)/c will be picked to death during code review, or in modern times, perhaps picked to death automatically by a tool that checks for verboten constructs. In this environment, that programmer should instead have written something along the lines of div(add(a,b),c) (and possibly some checking for error status). Underneath the hood, the div (and also the add) functions/macros protects against division by zero (or overflow in the case of add). What that protection entails is very implementation specific.

• Just because NaN doesn't obey the arithmetic you learned in school doesn't mean it makes no sense. It obeys different arithmetic – Caleth Aug 1 '18 at 16:03

We know by now that x/0 and 0/0 do not have well defined answers. What happens if you attempt to calculate 0/0 anyway?

On a modern system, the calculation is passed to the MPU within the CPU and is flagged as an illegal operation, returning NaN.

On a much older system, such as '80s home computers that had no on-chip division, the calculation was done by whatever software was running. There are a few possible choices:

• Subtract smaller and smaller copies of the divisor until the value reaches zero and keep track of which sized copies were subtracted
• If it checks for zero before the first subtraction, it will exit quickly and the result will be 0
• If it assumes it must be able to subtract at least once, the result will be 1
• Calculate the logarithms of both numbers, subtract them and raise e to the power of the result. A very inefficient method compared to the above subtraction method, but mathematically valid
• An overflow might occur trying to calculate log(0) and the software would either use its error handling routines, or crash
• The software might assume that all logarithms can be calculated in a fixed number of steps and return a large, but incorrect value. Since both logarithms would be the same, the difference would be 0 and e0 = 1, giving a result of 1

In other words, it would be implementation dependant what would happen and it would be possible to write software that produces correct and predictable results for every value but seemingly strange values for 0/0 that are nonetheless, still internally consistent.

• This question is about dividing by zero in the integers, and there is no such thing as NaN in the integers. – David Hammen Feb 27 '16 at 21:56
• No CPU is going to calculate logs and subtract to calculate the result of division. Logarithm instruction timing is several orders of magnitude greater than a division. What is the value of log(0)? – wallyk Feb 27 '16 at 22:00
• @DavidHammen The OP never once mentioned integers, and nor did anyone who commented on the question. Integers are only mentioned in answers. – CJ Dennis Feb 29 '16 at 3:24
• @wallyk I already said in my answer that that logarithms are very inefficient for division. The cost for arithmetic is (addition = subtraction) <= multiplication <= division. If you don't have an MPU that can do division in the same number of clock cycles as addition (usually one), then division is more expensive than addition and subtraction and usually more expensive than multiplication too. – CJ Dennis Feb 29 '16 at 3:30