为什么GCC在执行1/0时会报告浮点异常？

Question

Stroustrup says, in "The Design and Evolution of C++" (Addison Wesley, 1994), "low-level events, such as arithmetic overflows and divide by zero, are assumed to be handled by a dedicated lower-level mechanism rather than by exceptions. This enables C++ to match the behaviour of other languages when it comes to arithmetic. It also avoids the problems that occur on heavily pipelined architectures where events such as divide by zero are asynchronous."

Q1: If it's not an exception, why does GCC report one as opposed to a lower-level error?

Q2: Given I'm dividing integers, why is it reported as floating point ?

Given I cannot catch it with catch(...), it is very misleading. Obviously I can test and avoid the whole 'error', but my point is that it is very confusing for a beginner who thinks that it might be an exception (reasonable), tries to catch it , then finds out that it's NOT AN EXCEPTION , and wonders about the run-time exception reported.

My compiler is gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

Some accurate clarification of the difference between CPU exceptions, FPU exceptions, Language exceptions and OS exceptions might resolve this.

Example Program:

int main(){
    int i=1/0;
    return i;
}

Resulting Output:

Floating point exception

Answer 1

A floating-point exception (FPE) is not a C++ exception. There are several types of exceptions in various systems, and they are not interchangeable. An FPE is an exception at the microprocessor or ISA level, but not at the C++ level. An FPE may result in the firing of a signal called SIGFPE, which you can handle but not using C++ try/catch. If you want to handle it you can use the POSIX function sigaction (I think on Windows one would use Structured Exception Handling).

Answer 2

Exceptions, in the C++ sense, are software-detected errors. When you divide by zero, its typically the hardware that detects the issue and it asserts a hardware exception (same name, similar concept, different beast). The operating system's hardware exception handler receives this and decides what to do. A typical OS reaction is to send a signal to the process that was running at the time of the hardware exception (if the system was running in user mode), and let that process's signal handler decide how to handle things.

Answer 3

Ancient history folded both floating point error and division by zero into SIGFPE. While you can on receiving the exception decode it to determine which, the shell doesn't.

Answer 4

The following little program catches a floating point error and prints out information about the signal. Note that from a C language standpoint a division by zero is undefined behavior. For example, not all systems have POSIX signals. Because the compiler can trivially predict the error, it may even on POSIX systems decide to simply eliminate all code, or exit immediately with an error. (I would hope and assume that a compiler on POSIX systems will produce a program which does the expected thing. Below it does. But such hopes have been disappointed before.)

#include <stdio.h>
#include <signal.h>
#include <stdlib.h> // for exit()

void fpehandler (int sig, siginfo_t *info, void *uc) 
{
    fprintf (stderr, 
            "Caught signal no. %d; code: %d (FPE_INTDIV would be %d)\n", 
            sig, info->si_code, FPE_INTDIV);
    if(info->si_code == FPE_INTDIV)
    {
        fprintf (stderr, 
                "Yes, the error was an integer division by zero.\n");
    }

    // It's not officially safe to return from a handler
    // of a "program error signal" (of which SIGFPE is an example).
    // Plus many functions are not strictly safe to 
    // call in a signal handler (e.g. exit()).
    // See https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers .
    // We call _Exit().
    _Exit(0); // success, isn't it?
}

int main(void)
{
    struct sigaction sa;
    sigemptyset (&sa.sa_mask);
    sa.sa_flags = SA_SIGINFO;
    sa.sa_sigaction = fpehandler;
    sigaction (SIGFPE, &sa, NULL);

    // cause "floating point" error 
    printf("%d\n", 2/0);

    // ---- below is unreachable code ;-) ----------

    // We shouldn't be here. Something went wrong. return 1.
    return 1;            
}

When I run it under cygwin, gcc 5.4.0, it prints

$ gcc -Wall float-except.c -o float-except && ./float-except
float-except.c: In function 'main':
float-except.c:28:21: warning: division by zero [-Wdiv-by-zero]
     printf("%d\n", 2/0);
                     ^
Caught signal no. 8; code: 15 (FPE_INTDIV would be 15)
Yes, the error was an integer division by zero.