18

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.)

Taymon
  • 24,950
  • 9
  • 62
  • 84
  • 1
    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. – Crashworks Jun 03 '16 at 00:41
  • Related: [On which platforms does integer divide by zero trigger a floating point exception?](https://stackoverflow.com/questions/37262572/on-which-platforms-does-integer-divide-by-zero-trigger-a-floating-point-exceptio). TL:DR: POSIX requires it to be SIGFPE if there's a signal at all. – Peter Cordes Sep 23 '17 at 12:17

4 Answers4

24

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".

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
6

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.

  • You seem to be right: according to [this reference](http://www.teach.cs.toronto.edu/~ajr/258/pdp11.pdf), `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](http://gunkies.org/wiki/FP11_floating_point) FP11 – the PDP-11's newer FPU – did support trapping. So indeed there was no need initially for an integer division error signal name. – Ruslan Mar 30 '18 at 21:22
5

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.)

millimoose
  • 39,073
  • 9
  • 82
  • 134
1

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.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
  • 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. – Peter Cordes Oct 12 '16 at 16:25
  • @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. – Ruslan Mar 30 '18 at 21:27