Submitter: CFP
Submission Date: 2024-11-24
Document: WG14 N3401
Title: SIGFPE and I/O, version 2
Reference Documents: N3301, N3378

Summary

7.12.2#1 says that SIGFPE is not allowed to be raised for any <math.h> function.

However, SIGFPE could be raised for:

• the math functions in <tgmath.h> and <complex.h>
• input/output functions in <stdio.h>
• numeric conversion functions in <stdlib.h> and <wchar.h>

For example, scanf or strtod of 1e999999 is an overflow. And, catanh(1.0) is a pole error.

The main problem with SIGFPE is the user's program cannot recover once it has been signaled (since it is undefined behavior). That is, as per "7.14.2.1 The signal function", paragraph 3 [taking about a signal handler],

If and when the function returns, if the value of sig is SIGFPE, SIGILL, SIGSEGV, or any other implementation-defined value corresponding to a computational exception, the behavior is undefined; otherwise the program will resume execution at the point it was interrupted.

The better alternative to altering flow of control via signal handlers for SIGFPE is floating-point exception flags, such as the ones required by IEC 60559. The user has control of when the flags are tested.

We have not been told of any implementations that raise SIGFPE in Standard C library functions, except as an extension.

We have been told of an implementation that will raise SIGFPE in <math.h> functions. This only happens after the user's program has called an implementation provided extension function feenableexcept(). This is also mentioned in "J.5 Common extensions" clause "J.5.19 Math error reporting"

Functions declared in <complex.h> and <math.h> raise SIGFPE to report errors instead of, or in addition to, setting errno or raising floating-point exceptions (7.3, 7.12).

Proposals (can do more than one)

1. Add to "7.1.4 Use of library functions" another bullet:

   A library function (other than raise) shall execute without raising SIGFPE.

   Change "7.12.2 Treatment of error conditions" #1:
   

   ...as if it were a single operation without raising SIGFPE and without generating any of the floating-point exceptions "invalid", "divide-by-zero", or "overflow" except to reflect the result of the function.

   to

   ...as if it were a single operation without generating any of the floating-point exceptions "invalid", "divide-by-zero", or "overflow" except to reflect the result of the function (and without raising SIGFPE).

2. Add to <complex.h> "7.3.1 Introduction" a new paragraph:

   The functions in the following subclauses shall execute without raising SIGFPE.

   If this is done, it appears that there is no need to add the same to <tgmath.h>.

3. Add to "7.1.4 Use of library functions" another paragraph:

   Library functions (other than raise) shall execute without raising SIGFPE except as documented by the implementation.

4. Add to "7.1.4 Use of library functions" another paragraph:

   Recommended practice
   A library function (other than raise) should execute without raising SIGFPE.