[Cfp-interest 3193] improving the language of 7.12.2 "Treatment of error conditions"

[Jerome Coonen]

Work on the wording of pole errors inspired this suggestion to reconcile C
reporting requirements with the underlying computational circumstances.

*Suggestions:*

Change to add a new paragraph after 7.12.2p1

An error is said to *occur* when the underlying exceptional computational
condition arises and the error is reported using the mechanisms described
in this subclause. Not all exceptional conditions are required to be
reported as errors.


Change to the first sentence of 7.12.2p2

For all functions, a *domain error* can occur if and only if . . .


Change to the first sentence of 7.12.2p3


Similarly, a *pole error* can occur in cases where . . .


Change to the first sentence of 7.12.2p4


Likewise, a *range error* can occur if and only if . . .


*Rationale:*
The problem addressed here is that the current wording in section 7.12.2
specifies that "error X occurs if and only if condition Y is met", while
later on each function specification has language about which errors (must)
"occur" or "may occur".

That is, the unconditional specification in 7.12.2 is at odds with the
piecemeal function-by-function specification. The relaxed "can occur"
wording of this proposal bridges the gap between the computational context
(what exceptional cases arise) and the C execution context (which cases
must or may be reported).

Exceptional circumstances in the various functions can arise in a variety
of contexts. The issue may be mathematical, as in *log(0.0)*, or it may be
tied to the underlying arithmetic, as in overflow of a value too large to
represent. The C standard defines whether such circumstances can or must be
reported to users.

   - First, the new paragraph emphasizes that errors "occur" in the C
   domain.
   - Next , the three definitions connect domain, pole, and range errors to
   the underlying computational circumstances.
   - Finally, the long list of function definitions defines which errors
   must occur, while allowing implementations to report errors in other
   circumstances where such errors "can occur".

This change requires no implementation changes.

-Jerome Coonen
 650.996.4738
 jcoonen at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240813/f45e39bf/attachment.htm>