There are ‘flags’ which FP ops conditionally turn on to report events that some program’s need to sense, and others can ignore. Flags can be read by the program and they stay on until turned off by explicit program command.
The program provides ‘control bits’ which govern rounding modes. More control bits indicate which of the events that set flags should also cause a fault. I reserve “information” to refer to flags and control bits in the text below.
The general question concerns the ‘scope’ of such information. ‘Scope’ is vague so I innumerate some of the specific problem under this category:
One of the problems that muddy these questions is the expansion of the concept of subroutine to calls across protection boundaries. Other words for such concepts are ‘portal calls’ or ‘gate calls’. A portal call may be programmed by someone to an untrusted program that should not have access to this information. The programmer of that call site may not even have heard of this information and cannot be expected to stash the information away before the call and restore it afterwards. Also we have not postulated that it is possible for a program to set its flags. Some programming languages may even support such mistrust today, even for ‘normal calls’, except for issues such as these.
The problems outlined above appear even without trust issues. Concepts such as ‘current default rounding mode’ is considered to have the scope of a global variable, and has all of the problems that make global scope an unpopular concept. A program with no notion of FP may rely on two libraries each with their own incompatible strategies concerning this global state. Modern languages provide solutions to these dilemmas for data but not for this information. (C is not a modern language.) It is no wonder that the programmer who must detect ‘inexact value’ (a flag) must go outside the language spec to solve his problem. What ever he finds is unlikely to be portable.