<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;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Aug 18, 2024, at 4:02 PM, Jim Thomas <jaswthomas@sbcglobal.net> wrote:</div><br class="Apple-interchange-newline"><div><div><br><br><blockquote type="cite">On Aug 14, 2024, at 7:06 PM, Fred J. Tydeman <tydeman@tybor.com> wrote:<br><br>On Wed, 14 Aug 2024 15:42:44 -0700 Jerome Coonen wrote:<br><blockquote type="cite"><br> Fred: investigate range error issue for llogb(), which differs from<br>ilogb()<br></blockquote><br>7.12.7.10 The llogb functions<br><br>In paragraph 2, Change<br><br>If the correct value is outside the range of the return type, the<br>numeric result is unspecified.<br><br>to<br><br>If the correct value is outside the range of the return type, the<br>numeric result is unspecified and a domain error or range error may<br>occur.<br><br>Resaon<br><br>This is to be consistent with ilogb. Also, Annex H adds extended<br>floating-point types which could have exponent ranges that require<br>more than 32 bits (the minimum width of long int).<br></blockquote><br>Also, C (without Annex F) doesn’t place an upper limit for the size of the exponent for the standard floating types. <br><br><blockquote type="cite"><br>Aside: I would like: and a domain error shall occur<br>instead of what ilogb has. <br>Depends upon what we are doing with "may occur".<br></blockquote><br>So you would like two changes:<br><br>1. “may" to “shall”<br>It might be that errno is a legacy feature: implementations do what they have been doing and current users are adapted to that, and neither implementors nor users would benefit from a change. Hopefully new code is using floating-point exceptions instead of errno.<br><br>2. “domain error or range error" to "domain error"<br>Ugh. In C18 (and before), “a range error occurs if and only if the mathematical result of the function cannot be represented in an object of the specified type, due to extreme magnitude.” With this definition, a range error seems reasonable here, even though the result format is not a floating type and there is no overflow or underflow. In C23, "a range error occurs if and only if the result overflows or underflows, as defined below". An overflow requires returning the value of a HUGE_VAL macro which isn’t possible here. It appears the C23 definition is not compatible with the ilogb specification. This is not a problem for Annex F which requires a domain error, reported via an “invalid” floating-point exception, per ISO/IEC 60559.<br><br>- Jim Thomas<br></div></div></blockquote><div><br></div>This follows up on item 2 just above. </div><div><br></div><div>The C23 change to the range error definition excludes range errors for functions that return results in integer type. The C23 definition of range errors aligns with ISO/IEC 60559 which regards these cases as “invalid” floating-point exceptions, i.e. as domain errors. </div><div><br></div><div>However, the C23 change did not account for certain functions (e.g. <b>ilogb</b>, <b>lrint</b>, <b>lround</b>) that say if the correct/orunded value is outside the range of their integer return type, a domain error or range error may occur. The occurrence of a range error in these cases is now disallowed by the definition of range errors.</div><div><br></div><div> The following suggestions are intended to make the function specs consistent with the range error definition (essentially the C23 one), but avoid invalidating existing implementations or user code that provide or depend on a range error.</div><div><br></div><div>Suggestions:</div><div><br></div><div><div>1. For functions that return a result in integer type, remove any specification saying a range error may occur.</div><div><br></div><div>2. Insert after the first sentence in 7.12.2 #4: </div></div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>… Also, a range error may occur if the function result has integer type and the result is outside the range of the type; in such cases the occurrence of a range error is an obsolescent feature.</div></blockquote><div><br></div><div>- Jim Thomas</div><div><br><blockquote type="cite"><div><div><br><blockquote type="cite"><br><br>---<br>Fred J. Tydeman Tydeman Consulting<br>tydeman@tybor.com Testing, numerics, programming<br>+1 (702) 608-6093 Vice-chair of INCITS/C (ANSI "C")<br>Sample C17+FPCE tests: http://www.tybor.com<br>Savers sleep well, investors eat well, spenders work forever.<br><br>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></blockquote><br></div></div></blockquote></div><br></body></html>