The documentation (in the standards) for all of fenv.h
is rather confusing, but I'm especially confused about feholdexcept
and the concept of "non-stop mode" for a floating point exception. As far as I can tell, on any IEEE floating point implementation, exceptions are non-signaling/"non-stop" by default, and the fenv.h
interfaces seem to provide no way to enable a signaling mode unless it was the default. Is the whole concept of feholdexcept
useless except on non-IEEE systems or systems with nonstandard extensions for setting the signaling exception mask?
Asked
Active
Viewed 347 times
16

R.. GitHub STOP HELPING ICE
- 208,859
- 35
- 376
- 711
1 Answers
7
Suppose that you're implementing a library, and you don't know anything about what your callers might do the the floating-point environment before calling your code. They might unmask an exception, and install a custom trap handler that causes division-by-zero to produce the value 42. Suppose that your library depends on having default IEEE-754 behavior for division-by-zero. The feholdexcept
function gives you a means to enforce this behavior. The caller's environment, complete with their unmasked exception, can then be restored using the fesetenv
function.
This is admittedly a fairly obscure corner case of usage, but frankly everything in fenv.h
is fairly obscure to most programmers.

Stephen Canon
- 103,815
- 19
- 183
- 269
-
Considering that for the standard library, unless otherwise documented all functions need to be called in the default floating point environment to behave according to the specification, I think it would be pretty reasonable for third-party library authors to also put the burden on the calling application. Especially since any use of `fe*` functions might trigger the compiler (albeit not GCC...) to omit floating point optimizations that could cause exceptions to be lost... – R.. GitHub STOP HELPING ICE Jun 14 '11 at 04:22
-
1@R..: The `
` functions are generally somewhat lacking in both design and in documentation. I would go so far as to say that they might be the weakest feature of the C library. If you have any suggestions for improvements, I would be happy to pass them on to the C floating-point working group. – Stephen Canon Jun 14 '11 at 06:36