Both in the current proposed standard and in a further option being considered for "stricter" compliance with IEEE Std 754-2008, it is consistent with COBOL's history, intent, and direction that the language itself is not "interested" in arithmetic usng infinities. We do provide the capability of SETTING an infinity, and we do provide the capability of TESTING for infinity, but as a numeric value any representation of an infinity in an IEEE basic floating-point format WILL be detected as NOT NUMERIC and rejected as a numeric operand. |
Thus, the direction we're going is that everything COBOL DOES support wil/would be in conformance with IEEE 754 (by then, probably ISO/IEC/IEEE 60559), but we won't be providing ALL of the capabilities that that standard specifies (like, arithmetic results using infinities).
And, in general, if an overflow, underflow, invalid operation, or divide-by-zero exception is raised in an IEEE conversion or arithmetic operation, it qualifies as "a fatal" exception from COBOL's standpoint, and in such cases there is no guarantee as to what the result will be. All of these end up being handled under the historical "ON SIZE ERROR" conventions of that language.
In general, COBOL handles "inexact" according to its rules for "intermediate rounding"; it is expected that the appropriate predicate is applied to just about everything COBOL "tells" the IEEE library, so except in particular circumstances, the COBOL reaction to an "inexact" exception is "yeah, yeah, we know, go away, stop bothering me."
Are these adequate approaches from the standpoint of IEEE Std 754-2008?