SIGFPE

SIGFPE

General Computational Error

Default handling
Ignoring the signal
Information returned by siginfo
Notes on defining a handler
USS Considerations

The SIGFPE signal is raised whenever a computational error occurs. These errors include hexadecimal floating-point overflow or underflow, integer or hexadecimal floating point division by zero, and binary floating-point traps such as overflow and inexact. Note that integer overflow never causes a signal; when integer overflow occurs, the result is reduced to 32 bits or 64 bits, depending on type, by discarding the most significant bits and is then interpreted as a signed integer.

Default handling

The default handling for SIGFPE is to raise a more specific signal. One of the signals SIGBFPE, SIGFPDIV, SIGFPOFL, SIGFPUFL or SIGIDIV is raised. Note that SIGBFPE is raised for any binary floating-point (IEEE) trap. SIGFPDIV, SIGFPOFL and SIGFPUFL are raised only for hexadecimal floaating point. Handling of the more specific signal depends on whether a handler has been defined for it. Refer to the descriptions of each of these signals for more details.

Ignoring the signal

If your program ignores SIGFPE, the result of the computation that raises SIGFPE is undefined, unless the computation causes an underflow. For hexadecimal floating-point underflows, the result is set to zero.

Information returned by siginfo

If you call siginfo after a SIGFPE signal occurs, siginfo returns a pointer to a structure of type FPE_t. This structure is defined as:

typedef struct {
   int int_code; /* interrupt code */
   union {
      _ _near int *intv; /* 4-byte integer result */
      _ _near long long *llongv; /* 8-byte integer result */
      _ _near _ _hexfmt float *floatv; /* hex format float result */
      _ _near _ _hexfmt double *doublev; /* hex format double result */
      _ _near _ _binfmt float *bfloatv; /* bin format float result */
      _ _near _ _binfmt double *bdoublev;/* bin format double result */
   } result;
   _ _near char *EPIE: /* pointer to hardware program check info */
   _ _near double *fpregs; /* contents of floating regs 0,2,4,6 */
   _ _near double *fpregs16; /* contents of all floating regs */
   int res_size; /* size of result (0, 4 or 8) */
   int bfptrap; /* BFP exception bits for trap */
} FPE_t;

The int_code field contains the number of the more specific signal associated with this error, which will be one of SIGBFPE, SIGFPDIV, SIGFPOFL, SIGFPUFL, or SIGIDIV. The result field is a pointer to the result of the computation that raises the signal. If you want to continue processing, you can change the value that result points to. Note that the result field may be zero if a floating-point exception occurs in an instruction which has no result or an integer result.

The EPIE field is a pointer to a control block containing hardware information available at the time the signal occurs. (This information includes program status word and registers.) For information on the EPIE format, see the IBM publication MVS/XA Supervisor Services and Macro Instructions. The EPIE pointer always addresses a memory block mapped like an OS/390 EPIE, even in environments such as CICS where a different format is used internally.

The fpregs field is a pointer to an array of four doubles, containing the contents of floating point registers 0, 2, 4 and 6 at the time of the signal. The fpregs16 field is a pointer to an array of doubles containing the contents of all 16 floating point registers. (On systems with only 4 floating-point registers, the undefined registers are stored as zeroes.) Note that the register contents may be either in hexadecimal or binary format, and that a cast may possibly be needed to interpret them correctly.

The reg_size field indicates the size of the result, 4 for an int or float result, 8 for a long long or double result, and 0 for a case where no result pointer was stored.

he bfptrap field is meaningful only when int_code is SIGBFPE. Then, it contains one or more of the floating-point bits defined in fenv.h. For instance, if bfptrap is FE_OVERFLOW+FE_INEXACT, it indicates that the error was a combination of an overflow condition with the inexact condition.

Notes on defining a handler

If you define a handler for SIGFPE , you can determine what type of error caused the signal by testing the int_code field of the information returned by siginfo. You can also use this information to reset the result of the computation by changing the value that result points to. Refer to the example in the description of the siginfo function for an illustration of this technique.

USS Considerations

When SIGFPE is managed by USS, the default action for SIGFPE is abnormal process termination, and SIGFPE is never converted into another signal. If you want to handle one or more of the SIGBFPE, SIGFPDIV, SIGFPOFL, SIGFPUFL, or SIGIDIV signals specific to SAS/C, you must define SIGFPE as a signal managed by SAS/C.

Chapter Contents
Previous
Next
Top of Page