<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>Reading Fred and Vincent’s remarks led to the following thoughts.</div><div><br></div><div>A recent C2Y change (see N3405) separates the concepts of (1) the exceptional computational condition (e.g. overflow) and (2) the occurrence of an error, as expressed in 7.12.2 #2:</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>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.</div></div></blockquote><div><br></div><div>Some wording changes were made to align with this clarification. However, some mixing of the concepts remains.</div><div><br></div><div>7.12.2 #5 says</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>… Range errors that are required or implementation-defined shall or may be reported, as specified in this subclause, respectively.</div></blockquote><div><br></div><div>The “may” suggests errors can occur but not be reported, contradicting #2. Also, “respectively” is not applicable here. Consider the replacement</div><div><br></div><div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><span style="background-color: rgb(255, 251, 0);">… Range errors, whether required or implementation-defined, are reported as specified in this subclause.</span></blockquote></div><div><br></div><div>7.12.2 #6 says</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>… If a floating result overflows and default rounding is in effect and the integer expression <font face="Courier New">math_errhandling & MATH_ERRNO</font> is nonzero, then the integer expression <font face="Courier New">errno</font> acquires the value <font face="Courier New">ERANGE</font>. If a floating result overflows, and the integer expression <font face="Courier New">math_errhandling & MATH_ERREXCEPT</font> is nonzero, the "overflow” floating-point exception is raised (regardless of whether default rounding is in effect).</div></blockquote><div><div><br></div><div>This appears to say that when the exceptional computational condition (overflow) occurs it must be reported (with a qualification about default rounding). However, the intention is only to say how errors are reported. Consider changing to</div><div><br></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><span style="background-color: rgb(255, 251, 0);">… If a range error occurs because of floating-point overflow and the integer expression <font face="Courier New">math_errhandling & MATH_ERRNO</font> is nonzero, the integer expression <font face="Courier New">errno</font> acquires the value <font face="Courier New">ERANGE</font>. If a range error occurs because of floating-point overflow and the integer expression <font face="Courier New">math_errhandling & </font><font face="Courier New">MATH_ERREXCEPT</font> is nonzero, the “overflow” floating-point exception is raised.</span></div></div></blockquote><div><div><br></div><div>and in #3, before the last sentence, inserting</div><div><div><br></div></div><blockquote style="margin: 0px 0px 0px 40px; border: medium; padding: 0px;"><div><span style="background-color: rgb(255, 251, 0);">Range errors in non-default rounding modes are implementation defined.*)</span></div><div><span style="background-color: rgb(255, 251, 0);"><br></span></div><div><span style="background-color: rgb(255, 251, 0);">*) Annex F specification for “overflow" and “underflow" floating-point exceptions applies to all IEC 60559 rounding modes.</span></div></blockquote><div></div><div><br></div><div>7.12.2 #7 says reporting underflow is implementation defined. However, some function specifications say "a range error occurs" for underflow conditions. E.g. the sin() specification says “A range error occurs if nonzero x is too close to zero.” Given #2, this implies required reporting. (The vagueness of “too close to zero” might give license for not reporting clear underflow conditions, but that Is not its intent.) Consider finding all such cases and replacing “occurs” with “<span style="background-color: rgb(255, 251, 0);">may occur</span>”. This change would allow removing the text about implementation defined reporting in 7.12.2 #7. Consider the replacement</div></div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><span style="background-color: rgb(255, 251, 0);">… If the result underflows, the function returns an implementation-defined value whose magnitude is no greater than the smallest</span></div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><span style="background-color: rgb(255, 251, 0);">normalized positive number in the specified type. If a range error occurs because of floating-point underflow and the integer expression <font face="Courier New">math_errhandling & MATH_ERRNO</font> is nonzero, the integer expression <font face="Courier New">errno</font> acquires the value <font face="Courier New">ERANGE</font>. If a range error occurs because of floating-point underflow and the integer expression <font face="Courier New">math_errhandling & MATH_MATH_ERREXCEPT</font> is nonzero, the “underflow" /floating-point exception is raised.</span></div></div></blockquote><div><br></div><div>In order to not lose the “implementation defined” requirement we could add in #3, #4 and #5 the statement </div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><span style="background-color: rgb(255, 251, 0);">Function descriptions say a xxx error “may error” to indicate some of the cases suitable for implementation defined errors.</span></div></blockquote><div><br></div><div>A simplification would be to append to #2</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><span style="background-color: rgb(255, 251, 0);">The description of each function lists any required errors. An implementation may define additional errors, provided that such errors are consistent with the mathematical definition of the function and the meaning of the exceptional condition. Function descriptions say an error “may error” to indicate some of the cases suitable for implementation defined errors.</span></div><div><br></div></blockquote><div>and remove the specification “<strike style="background-color: rgb(255, 251, 0);">The description of each function lists …; an implementation may define …</strike>” that is repeated for each type of exceptional condition. </div><div><br></div><div>- Jim Thomas</div><div><br></div><div><div><br><blockquote type="cite"><div>On Aug 4, 2025, at 6:20 AM, Vincent Lefevre <vincent@vinc17.net> wrote:</div><br class="Apple-interchange-newline"><div><div>On 2025-08-04 09:56:02 +1000, Fred J. Tydeman wrote:<br><blockquote type="cite">In reading 7.12.1 on "overflow", I do not see any words on what<br>happens to errno on overflow in non-default rounding.<br><br>Normally, if nothing is said, that means implicit Undefined Behaviour.<br>I assume we would want implementation-defined behaviour or<br>alter to ERANGE.<br></blockquote><br>I don't think that this could be undefined behavior. 7.12.1 starts<br>with:<br><br> The behavior of each of the functions in <math.h> is specified<br> for all representable values of its input arguments, except<br> where explicitly stated otherwise.<br><br>So any undefined behavior would have to be explicit here.<br><br>For errno, if nothing is specified here under the considered<br>conditions, one would just get the default behavior for arbitrary<br>library functions, as specified in 7.5 "Errors <errno.h>":<br><br> The value of errno may be set to nonzero by a library function call<br> whether or not there is an error, provided the use of errno is not<br> documented in the description of the function in this document.<br><br>-- <br>Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/><br>100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/><br>Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)<br>_______________________________________________<br>cfp-interest mailing list<br>cfp-interest@oakapple.net<br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></div></div></blockquote></div><br></div></div></body></html>