Why does integer division by zero result in a floating point exception?

Question

Division by zero in a C program results in abnormal termination with the error message Floating point exception (core dumped). This is unsurprising for floating point division, but why does it say this when integer division by zero occurs? Does integer division actually use the FPU under the hood?

(This is all on Linux under x86, by the way.)

Grateful

Worth noting that other non-POSIX operating systems (eg Windows) and the x86 hardware report different exceptions for integer and floating-point divide by zero. – Turnabout

Related: On which platforms does integer divide by zero trigger a floating point exception?. TL:DR: POSIX requires it to be SIGFPE if there's a signal at all. – Police

Answer 1

Does integer division actually use the FPU under the hood?

No, Linux just generates SIGFPE in this case too (it's a legacy name whose usage has now been extended). Indeed, the Single Unix Specification defines SIGFPE as "Erroneous arithmetic operation".

Semiramis

Answer 2

My guess at a historical explanation for this would be that the original unix hardware didn't generate a trap on integer division by zero, so the name SIGFPE made sense. (PDP assembly programmers, confirm?) Then later when the system was ported (or in the case of Linux, reimplemented) to hardware with an integer division-by-zero trap, it was not considered worthwhile to add a new signal number, so the old one acquired a new meaning and now has a slightly confusing name.

Multitudinous

You seem to be right: according to this reference, DIV instruction simply sets C and V flags on division by zero, and V flag only if the result doesn't fit in the destination register. OTOH, according to this page FP11 – the PDP-11's newer FPU – did support trapping. So indeed there was no need initially for an integer division error signal name. – Mule

Answer 3

man signal mentions:

Integer division by zero has undefined result. On some architectures it will generate a SIGFPE signal. (Also dividing the most negative integer by -1 may generate SIGFPE.)

Icsh

Answer 4

There could be many different implementation-specific reasons for that.

For example, the FPU unit on x86 platform supports both floating point and integer formats for reading arguments and writing results. Back when the platform itself was 16-bit, some compilers used the FPU to perform division with 32-bit integer operands (since there's no precision loss for 32-bit wide data). Under such circumstances there would be nothing unusual in getting a genuine FPU error for invalid 32-bit integer division.

Wink

FP exceptions are normally masked, so you just get a NaN or +/-Inf result instead of an exception. I wonder if the SIGFPE for integer division exceptions convention/tradition started before x86? Unix couldn't be properly ported to x86 until 386 (protected mode), but some Unix-like environments without real memory protection existed, I think. – Police

@PeterCordes it seems ELKS at least did try to port Linux not only to 286, but even to 8086. I have even run it on a 286 machine. I suppose UNIX also could be ported. – Mule