There are piles of what would seem to be trivial issues that boil down to agreement on the names to be used for various flags, traps and actions. Since the bit patterns for registers are not legislated, mode mapping varies from platform to platform, and there must be names for the bit positions.
C9X provides a type fenv_t with the intent to represent the entire floating-point environment.
C9X gives following names (as macros) for flags in the floating-point environment:
FE_DIVBYZERO FE_INEXACT FE_INVALID FE_OVERFLOW FE_UNDERFLOW with FE_ALL_EXCEPT representing the bitwise OR of the above.
Additionally,
FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARDare macros defined iff the implementation supports testing (get) and setting rounding direction by means of fegetround and fesetround functions.
If the programmer intends to access fenv in a non-default way, then the program must include
#include <fenv.h> #pragma STDC FENV_ACCESS on-off-switch //pragma lasts until end of ``translation unit''
note:failure to set pragma and then setting flags leads to an ``undefined program.''
feset_except, fetest_except, feraise_exceptfunctions are provided, though the prospect of using them to raise signals and have the C language deal with them is implementation dependent, and could apparently be ignored without affecting the validity of the implementation. (C9X section 7.11)
If the implementation so chooses, there are possibilities for SIG_DFL (default) handling or SIG_IGN (ignore) handling, or a user-inserted function with limited access to variables or serious functions. It appears to be possible to return to a place where an exception was raised by a RAISE function.
//example in C9X #pragma STDC FENV_ACCESS ON int save_round; int setround_ok; save_round=fegetround(); setround_ok=fesetround(FE_UPWARD); assert(setround_ok); //bomb if rounding mode inaccessible /*compute something in here */ fesetround(save_round); /*etc*
Incidentally, the Modula-3 language words are all different...