On Sat, 1 Mar 2025 11:43:11 +0000 Andrew Josey via austin-group-l at The Open Group wrote: > >We spent the meeting discussing a liaison question from Dave Banham in the ISO >C group. > >"I am wondering what the Austin Groups position is on the paper >N3401 "SIGFPE and I/O, version 2" >(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3401.htm) is? > >My concern is that it seems to suggest that SIGFPE cannot arise >as a result of domain errors in the math and I/O functions. >Part of the problem seems to be that whilst the C Standard >defines the SIGFPE signal is does not indicate what the default >signal handling behaviour is, nor whether floating point >exceptions can actually result in a SIGFPE signal. And I note >that the typical function for enabling this is feenableexcept(), >which lies outside of the POSIX standard's scope too. Thoughts?" > >Of the proposal in N3401, option 3 seems the most reasonable to the >Austin Group; however, POSIX follows the C standard, and will >continue to do so. It is noted that many Linux, BSD and other systems >do support the feenableexcept() mechanism to request SIGFPE for >certain conditions, and these systems do raise a SIGFPE from these >library functions.
For those cases, what happens when a signal handler for SIGFPE returns? The C standard says it is undefined behavior. The committee went with option 4 Recommended practice. --- Fred J. Tydeman Tydeman Consulting [email protected] Testing, numerics, programming +1 (702) 608-6093 Vice-chair of INCITS/C (ANSI "C") Sample C17+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever.
