3

This is from The GNU C Library Reference Manual

int SIGFPE

The SIGFPE signal reports a fatal arithmetic error. This signal actually covers all arithmetic errors, including division by zero and overflow.

BSD systems provide the SIGFPE handler with an extra argument that distinguishes various causes of the exception. In order to access this argument, you must define the handler to accept two arguments, which means you must cast it to a one-argument function type in order to establish the handler.

But there is no example on how to access the extra argument.

I did my google work but could not find anything.

How can I get this extra information?

Koray Tugay
  • 22,894
  • 45
  • 188
  • 319
  • Same way you access any function argument -- by the name you gave the formal parameter. – Ben Voigt Jun 03 '15 at 18:48
  • @BenVoigt Sorry I am not very experienced with System Programming and C. What do you mean by your comment? – Koray Tugay Jun 03 '15 at 18:48
  • 3
    Why not use `sigaction()` rather than the obsolete(ish) `signal()`, and enjoy the pleasures of getting a `struct siginfo*` full of goodness? – EOF Jun 03 '15 at 18:49
  • @RossRidge Fixed the tags, sorry. – Koray Tugay Jun 03 '15 at 18:50
  • @EOF I am really just reading the Manual right now. – Koray Tugay Jun 03 '15 at 18:53
  • @KorayTugay: When you define a function, you provide a signature which contains a type and name for each argument. Inside that function, using that name (called a formal parameter) accesses the value passed by the caller (called an actual parameter). – Ben Voigt Jun 03 '15 at 18:58
  • @BenVoigt Can you at least give a simple example to this so I can understand? Examples are always better for me. – Koray Tugay Jun 03 '15 at 18:59
  • 1
    @KorayTugay: Every C program starts with `int main(int argc, char** argv)` and you access the arguments by their names `argc` and `argv`. When you create a function to handle your signals, you will give names to the arguments. – Ben Voigt Jun 03 '15 at 19:00

2 Answers2

4

As EOF mentioned in the comments, the much better way to do this, that doesn't require formally broken casts, and a bonus is correctly documented, is to install your signal handler using sigaction and the SA_SIGINFO flag, and then in the si_code field of the second parameter (type siginfo_t) you can determine which floating-point error occurred:

The following values can be placed in si_code for a SIGFPE signal:

FPE_INTDIV Integer divide by zero.

FPE_INTOVF Integer overflow.

FPE_FLTDIV Floating-point divide by zero.

FPE_FLTOVF Floating-point overflow.

FPE_FLTUND Floating-point underflow.

FPE_FLTRES Floating-point inexact result.

FPE_FLTINV Floating-point invalid operation.

FPE_FLTSUB Subscript out of range.

Source: Linux sigaction(2) man page

The same list is also readily available on the FreeBSD siginfo man page.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
1

The information that glibc refers to is a historic mechanism, and is not portable. On FreeBSD, the sigvec(2) manual page includes a notation that it is only supported on the VAX-11 architecture:

On the VAX-11 The handler routine can be declared:

void  handler(sig, code, scp)
int sig, code;
struct sigcontext *scp;

Here sig is the signal number, into which the hardware faults and traps are mapped as defined below. The code argument is either a constant as given below or, for compatibility mode faults, the code provided by the hardware (Compatibility mode faults are distinguished from the other SIGILL traps by having PSL_CM set in the psl). The scp argument is a pointer to the sigcontext structure (defined in <signal.h>), used to restore the context from before the signal.

The mapping list is not actually provided in this version of the manpage. It can be found in the 4.3BSD-Reno signal(3) manpage. It's worth noting that this text is 25 years old.

On modern systems, you should use the sigaction mechanism, which is much more well-defined and portable.

BUGS - This manual page is still confusing.

Indeed it is.

Random832
  • 37,415
  • 3
  • 44
  • 63