<html><body><p><font size="2" face="sans-serif">This is the paper I intend to send to WG14 on behalf of CFP as per my action item from todays meeting:</font><br><br><font size="2" face="sans-serif">Some members of the WG21 committee seem to be concerned with the expansion in scope in freestanding environments in C23 due to the changes brought in from the integration of TS 18661. This paper tries to address the concerns brought forward in WG14 reflector messages 19444 and 19445.</font><br><br><font size="2" face="sans-serif">Two alternatives are proposed. The first one is intended to reduce the scope of changes brought in by the TS to remove requirements for thread local storage (errno) and modification to global state (the floating point environment), and does so in a general way. The second alternative is to let implementations choose between having errno or modifying global state (the floating point exception states) or both where possible, and does so by modifying functions that require errno directly. Note that the second alternative does not remove the need to modify global state in cases outside certain functions. For example, setting and clearing floating point exception flags are required.</font><br><br><font size="2" face="sans-serif">Note for alternative 1: The practical set of functions in the fenv.h header seem to be only fegetround and fe_dec_getround, but the other query functions were listed as well since they do not modify global state either. The reduced list of functions is a possibility as well if alternative 1 is chosen.</font><br><br><font size="2" face="sans-serif">Alternative 1: In N2596, change Section 4#7 to:</font><br><br><font size="2" face="sans-serif">The strictly conforming programs that shall be accepted by a conforming freestanding implementation that defines __STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ may also use features, without the requirements to set errno (see 7.5) or modify the floating point environment (see 7.6) in the following:</font><br><font size="2" face="sans-serif">- all the macros and the following functions in <fenv.h>: fegetexceptflag, fetestexceptflag, fetestexcept, fegetmode, fegetround, fe_dec_getround, fegetenv</font><br><font size="2" face="sans-serif">- <math.h></font><br><font size="2" face="sans-serif">- the numeric conversion functions (7.22.1) of the standard header <stdlib.h> </font><br><font size="2" face="sans-serif">All identifiers that are reserved when <stdlib.h> is included in a hosted implementation are reserved when it is included in a freestanding implementation.</font><br><br><br><font size="2" face="sans-serif">Alternative 2: In N2596 change 7.22.1.5#10 to:</font><br><br><font size="2" face="sans-serif">The functions return the converted value, if any. If no conversion could be performed, zero is returned. If the correct value overflows and default rounding is in effect (7.12.1), plus or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned (according to the return type and sign of the value); the value of the macro ERANGE is stored in errno if the integer expression math_errhandling & MATH_ERRNO is nonzero; and the "overflow" floating-point exception is raised if the integer expression math_errhandling & MATH_ERREXCEPT is nonzero.</font><br><br><font size="2" face="sans-serif">If the result underflows (7.12.1), the functions return a value whose magnitude is no greater than the smallest normalized positive number in the return type; whether errno acquires the value ERANGE if the integer expression math_errhandling & MATH_ERRNO is nonzero is implementation defined. If the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, whether the "underflow" floating-point exception is raised is implementation-defined.</font><br><br><font size="2" face="sans-serif">Change 7.22.1.6#7 to:</font><br><br><font size="2" face="sans-serif">The strtodN functions return the correctly rounded converted value, if any. If no conversion could be performed, the value of the triple (+1, 0, 0) is returned. If the correct value overflows:</font><br><font size="2" face="sans-serif"> - the value of the macro ERANGE is stored in errno if the integer expression math_errhandling & MATH_ERRNO is nonzero</font><br><font size="2" face="sans-serif"> - the "overflow" floating-point exception is raised if the integer expression math_errhandling & MATH_ERREXCEPT is nonzero</font><br><font size="2" face="sans-serif">If the result underflows (7.12.1), whether errno acquires the value ERANGE if the integer expression math_errhandling & MATH_ERRNO is nonzero is implementation defined. If the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, whether the "underflow" floating-point exception is raised is implementation-defined.</font><br><br><font size="2" face="sans-serif">Change 7.22.1.7#8 to:</font><br><br><font size="2" face="sans-serif">The strtol, strtoll, strtoul, and strtoull functions return the converted value, if any. If no conversion could be performed, zero is returned. If the correct value is outside the range of representable values, LONG_MIN, LONG_MAX, LLONG_MIN, LLONG_MAX, ULONG_MAX, or ULLONG_MAX is returned (according to the return type and sign of the value, if any), and:</font><br><font size="2" face="sans-serif"> - the value of the macro ERANGE is stored in errno if the integer expression math_errhandling & MATH_ERRNO is nonzero</font><br><font size="2" face="sans-serif"> - the "overflow" floating-point exception is raised if the integer expression math_errhandling & MATH_ERREXCEPT is nonzero</font><br><br><font size="2" face="sans-serif">Regards,<br><br></font><font size="2" face="sans-serif"><b>Rajan Bhakta</b></font><font size="2" face="sans-serif"><br>z/OS XL C/C++ Compiler Technical Architect<br>ISO C Standards Representative (Canada, USA), PL22.11 Chair<br>C/C++ Compiler Development</font><br><font size="2" face="sans-serif">rbhakta@us.ibm.com</font><br><br><font size="2" face="sans-serif">IBM</font><br><font size="1" color="#800080" face="sans-serif">----- Forwarded by Rajan Bhakta/Houston/IBM</font><font size="1" color="#800080" face="sans-serif"> on 09/29/2021 04:08 PM</font><font size="1" color="#800080" face="sans-serif"> -----</font><br><br><font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">"Jim Thomas" <jaswthomas@sbcglobal.net></font><br><font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"Rajan Bhakta" <rbhakta@us.ibm.com></font><br><font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">09/28/2021 04:28 PM</font><br><font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">[EXTERNAL] Re: [Cfp-interest 2140] Freestanding with FP binding - wording</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font size="1" color="#FFFFFF" face="serif">On Sep 28, 2021, at 1:47 PM, Rajan Bhakta <rbhakta@us.ibm.com> wrote: From: "Jim Thomas" <jaswthomas@sbcglobal.net> To: "Rajan Bhakta" <rbhakta@us.ibm.com> Date: 09/28/2021 12:27 PM Subject: žžžžžžžžžžžžžžžžžžžžžžžžžžžžžžZjQcmQRYFpfptBannerStart</font><font size="3" face="serif"> </font><br><font size="2" face="Arial"><b>This Message Is From an External Sender </b></font><br><font size="1" face="Arial">This message came from outside your organization. </font><br><font size="1" color="#FFFFFF" face="serif">ZjQcmQRYFpfptBannerEnd</font><font size="3" face="serif"><br></font><br>
<ul style="padding-left: 36pt; margin-left: 0px"><font size="3" face="serif">On Sep 28, 2021, at 1:47 PM, Rajan Bhakta <</font><a href="mailto:rbhakta@us.ibm.com"><font size="3" color="#0000FF" face="serif"><u>rbhakta@us.ibm.com</u></font></a><font size="3" face="serif">> wrote:</font><br>
<p><font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">"Jim Thomas" <</font><a href="mailto:jaswthomas@sbcglobal.net"><font size="1" color="#0000FF" face="sans-serif"><u>jaswthomas@sbcglobal.net</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5F5F5F" face="sans-serif"><br>To: </font><font size="1" face="sans-serif">"Rajan Bhakta" <</font><a href="mailto:rbhakta@us.ibm.com"><font size="1" color="#0000FF" face="sans-serif"><u>rbhakta@us.ibm.com</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5F5F5F" face="sans-serif"><br>Date: </font><font size="1" face="sans-serif">09/28/2021 12:27 PM</font><font size="1" color="#5F5F5F" face="sans-serif"><br>Subject: </font><font size="1" face="sans-serif">[EXTERNAL] Re: [Cfp-interest 2140] Freestanding with FP binding - wording</font><p><font size="3" face="serif">On Sep 17, 2021, at 8:43 AM, Rajan Bhakta <</font><a href="mailto:rbhakta@us.ibm.com"><font size="3" color="#0000FF" face="serif"><u>rbhakta@us.ibm.com</u></font></a><font size="3" face="serif">> wrote:</font><p><font size="2" face="sans-serif">Here are some words for both alternatives listed in CFP 2085 (attached) below.<br>Note that the words for alternative (1) can be further specified in terms of actual changes to all the specification for the contents of the headers that we now allow in fenv.h and math.h and stdlib,h, but I think that would reduce clarity and be more fragile and prone to error. Hence a minimal change is proposed alone.</font><font size="3" face="serif"><br></font><font size="2" face="sans-serif"><br><br>For alternative (1), in N2596, change Section 4#7 from:<br><br>The strictly conforming programs that shall be accepted by a conforming freestanding implementation that defines __STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ may also use features in the contents of the standard headers <fenv.h> and <math.h> and the numeric conversion functions (7.22.1) of the standard header <stdlib.h>. All identifiers that are reserved when <stdlib.h> is included in a hosted implementation are reserved when it is included in a freestanding implementation.<br><br>to:<br><br>The strictly conforming programs that shall be accepted by a conforming freestanding implementation that defines __STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ may also use features in the contents of the standard headers <fenv.h> and <math.h> and the numeric conversion functions (7.22.1) of the standard header <stdlib.h> </font><font size="2" color="#0000FF" face="sans-serif"><b><br> without the requirements to set errno (see 7.5), or modify the floating point environment (see 7.6)</b></font><font size="2" face="sans-serif"><br>. All identifiers that are reserved when <stdlib.h> is included in a hosted implementation are reserved when it is included in a freestanding implementation.</font><p><font size="3" face="serif"><br>I believe the qualification “without” applies to “features” but they’re far enough apart to be confusing.</font><p><font size="3" face="serif"><Rajan> I can kind of see that. How about the following:</font><p><font size="2" face="sans-serif"><br>The strictly conforming programs that shall be accepted by a conforming freestanding implementation that defines __STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ may also use features<br>,</font><font size="2" color="#0000FF" face="sans-serif"><b> without the requirements to set errno (see 7.5),</b></font></ul><font size="3" face="serif">Omit the comma.</font><ul style="padding-left: 36pt; margin-left: 0px"><font size="2" color="#0000FF" face="sans-serif"><b>or modify the floating point environment (see 7.6),</b></font><font size="2" face="sans-serif"> in the following:<br>- </font><font size="2" color="#0000FF" face="sans-serif"><b>all the macros and the following functions in <fenv.h>: fegetexceptflag, fetestexceptflag, fetestexcept, fegetmode, fegetround, fe_dec_getround, fegetenv<br>- <math.h><br>- the numeric conversion functions (7.22.1) of the standard header <stdlib.h> </b></font><font size="2" face="sans-serif"><br>All identifiers that are reserved when <stdlib.h> is included in a hosted implementation are reserved when it is included in a freestanding implementation.</font></ul><br><font size="3" face="serif">Yes, this is better. </font><br>
<ul style="padding-left: 36pt; margin-left: 0px"><font size="3" face="serif"></Rajan><br><br>I don’t think we need to say anything about errno not being set, because on freestanding implementations the program can’t use <errno.h> features. Right?<br><Rajan/> I think we do need to say it, because "errno" is talked about in the features (functions) of math.h and hence we need to be explicit it is not included in the "use features" part.</font><br><font size="3" face="serif"><br><br>Does the restriction on modifying the floating-point environment apply to translation and execution? What features from <fenv.h> could the program use? If the only usable features are queries, there isn’t an issue with modifying the environment. If we could say which <fenv.h> features were useable, we wouldn’t have to say anything about removed requirements.<br><Rajan> Yes, the modifications apply to execution. </font></ul><br><font size="3" face="serif">Not to translation? This is relevant to whether the rounding mode pragmas can be used.</font><br>
<ul style="padding-left: 36pt; margin-left: 0px"><font size="3" face="serif">I would propose that testing the exception flags and other query functions should be allowed since none of those modifies the environment. This was added to the proposed change above. I left the "modify the floating point environment" present to ensure readers know we are not looking to have a requirement for additional state for freestanding. i.e. The query functions could return the defaults for the environment and since no changes are allowed, the functions would be the equivalent of something translation time resolved like macros.<br></Rajan></font></ul><br><font size="3" face="serif">I’m thinking the only two <fenv.h> functions that are potentially useful are fegetround and fe_dec_getround, given that the implementation can’t change the floating-point environment. For example, fegetmode returns an opaque representation of the modes that is good only for an argument to fesetmode. And there’s no point in testing for exception flags if the implementation isn’t required to set them.</font><ul style="padding-left: 36pt; margin-left: 0px"><font size="2" face="sans-serif"><br><br>For alternative (2), in N2596, change 7.22.1.5#10 (and similar changes for the rest of the family of functions) from:<br><br>The functions return the converted value, if any. If no conversion could be performed, zero is returned. If the correct value overflows and default rounding is in effect (7.12.1), plus or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned (according to the return type and sign of the value), and the value of the macro ERANGE is stored in errno. If the result underflows (7.12.1), the functions return a value whose magnitude is no greater than the smallest normalized positive number in the return type; whether errno acquires the value ERANGE is implementation-defined.<br><br>to:<br><br>The functions return the converted value, if any. If no conversion could be performed, zero is returned. If the correct value overflows and default rounding is in effect (7.12.1), plus or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned (according to the return type and sign of the value), and the value of the macro ERANGE is stored in errno</font><font size="2" color="#0000FF" face="sans-serif"><b><br> if the integer expression math_errhandling & MATH_ERRNO is nonzero. If the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, the "overflow" floating-point exception is raised.</b></font><font size="2" face="sans-serif"><br>If the result underflows (7.12.1), the functions return a value whose magnitude is no greater than the smallest normalized positive number in the return type; whether errno acquires the value ERANGE </font><font size="2" color="#0000FF" face="sans-serif"><b><br> if the integer expression math_errhandling & MATH_ERRNO is nonzero is implementation defined. If the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, whether the "underflow" floating-point exception is raised </b></font><font size="2" face="sans-serif"><br>is implementation-defined.</font><br><font size="3" face="serif"><br>Since all this is in one paragraph, it might help to group related sentences with semicolons, something like</font><br><font size="3" face="serif">If the correct value overflows and default rounding is in effect (7.12.1), plus or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned (according to the return type and sign of the value); the value of the macro ERANGE is stored in errno if the integer expression math_errhandling & MATH_ERRNO is nonzero; and the "overflow" floating-point exception is raised if the integer expression math_errhandling & MATH_ERREXCEPT is nonzero.</font><br><font size="3" face="serif">and similarly for underflows.<br><Rajan/> Hmmm, it can be possibly worded better, but I think we can leave this to the editor. I'm not sure the semicolon approach is better.</font></ul><br><font size="3" face="serif">As written, the sentence </font><br><br><font size="3" face="serif">"If the integer expression math_errhandling & MATH_ERREXCEPT is nonzero, the "overflow" floating-point exception is raised.” </font><br><br><font size="3" face="serif">would apply whether or not overflow occurs. Likewise for underflow.</font><ul style="padding-left: 36pt; margin-left: 0px"><font size="3" face="serif">Wouldn't this mean <stdlib.h> would have to define MATH_ERRNO, etc.? A different approach would be to define STDLIB_ERRNO, etc. and refer to them instead of MATH_ERRNO, etc..<br><Rajan/> True. I missed this. I think defining MATH_ERRNO in stdlib.h is probably better than adding in text for a new macro.<br><br>- Jim</font><br><font size="2" face="sans-serif"><br><br>Regards,</font><font size="2" face="sans-serif"><b><br><br>Rajan Bhakta</b></font><font size="2" face="sans-serif"><br>z/OS XL C/C++ Compiler Technical Architect<br>ISO C Standards Representative (Canada, USA), PL22.11 Chair<br>C/C++ Compiler Development</font><font size="3" color="#0000FF" face="serif"><u><br></u></font><a href="mailto:rbhakta@us.ibm.com"><font size="2" color="#0000FF" face="sans-serif"><u>rbhakta@us.ibm.com</u></font></a><font size="2" face="sans-serif"><br><br>IBM</font><font size="3" face="serif"><br><br><graycol.gif></font><font size="2" color="#424282" face="sans-serif">"Rajan Bhakta" ---08/05/2021 02:19:59 PM---Looking at the specification, I think the only thing that really works is to do something like the f</font><font size="1" color="#5F5F5F" face="sans-serif"><br><br>From: </font><font size="1" face="sans-serif">"Rajan Bhakta" <</font><a href="mailto:rbhakta@us.ibm.com"><font size="1" color="#0000FF" face="sans-serif"><u>rbhakta@us.ibm.com</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5F5F5F" face="sans-serif"><br>To: </font><a href="mailto:cfp-interest@oakapple.net"><font size="1" color="#0000FF" face="sans-serif"><u>cfp-interest@oakapple.net</u></font></a><font size="1" color="#5F5F5F" face="sans-serif"><br>Date: </font><font size="1" face="sans-serif">08/05/2021 02:19 PM</font><font size="1" color="#5F5F5F" face="sans-serif"><br>Subject: </font><font size="1" face="sans-serif">[EXTERNAL] [Cfp-interest 2085] Freestanding with FP binding</font><font size="1" color="#5F5F5F" face="sans-serif"><br>Sent by: </font><font size="1" face="sans-serif">"Cfp-interest" <</font><a href="mailto:cfp-interest-bounces@oakapple.net"><font size="1" color="#0000FF" face="sans-serif"><u>cfp-interest-bounces@oakapple.net</u></font></a><font size="1" face="sans-serif">></font><br><br><hr width="100%" size="2" align="left" noshade><font size="3" face="serif"><br></font><font size="1" color="#FFFFFF" face="serif"><br><br>Looking at the specification, I think the only thing that really works is to do something like the following: 1) Say for freestanding that error conditions do not necessarily have to be handled (including setting errno). This would have the ZjQcmQRYFpfptBannerStart</font><font size="3" face="serif"> </font><font size="2" face="Arial"><b><br>This Message Is From an External Sender </b></font><font size="1" face="Arial"><br>This message came from outside your organization. </font><font size="1" color="#FFFFFF" face="serif"><br>ZjQcmQRYFpfptBannerEnd</font><p><font size="2" face="sans-serif">Looking at the specification, I think the only thing that really works is to do something like the following:<br>1) Say for freestanding that error conditions do not necessarily have to be handled (including setting errno). This would have the new side effect of not requiring using exceptions as well.<br>or<br>2) Change the strtod family of functions to allow exceptions to be used for error reporting instead of just errno. This would be a change to the general C standard, but likely more palatable.<br><br>With regards to the whitespace and decimal point scanning, as long as we allow a freestanding implementation to have just the C locale (as it is now) and a single fixed code page, I think it would work for freestanding. The issues described in WG14 19444 still apply however meaning the code is not necessarily portable, but this may be something we either accept, or mandate that the C locale must be used.<br><br>Regards,</font><font size="2" face="sans-serif"><b><br><br>Rajan Bhakta</b></font><font size="2" face="sans-serif"><br>z/OS XL C/C++ Compiler Technical Architect<br>ISO C Standards Representative (Canada, USA), PL22.11 Chair<br>C/C++ Compiler Development</font><font size="3" color="#0000FF" face="serif"><u><br></u></font><a href="mailto:rbhakta@us.ibm.com"><font size="2" color="#0000FF" face="sans-serif"><u>rbhakta@us.ibm.com</u></font></a><font size="2" face="sans-serif"><br><br>IBM</font><tt><font size="2"><br>_______________________________________________<br>Cfp-interest mailing list</font></tt><font size="3" color="#0000FF" face="serif"><u><br></u></font><a href="mailto:Cfp-interest@oakapple.net"><tt><font size="2" color="#0000FF"><u>Cfp-interest@oakapple.net</u></font></tt></a><font size="3" color="#0000FF" face="serif"><u><br></u></font><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><font size="2" color="#0000FF"><u>http://mailman.oakapple.net/mailman/listinfo/cfp-interest</u></font></tt></a><tt><font size="2"> </font></tt><p><p><p><font size="3" face="serif">_______________________________________________<br>Cfp-interest mailing list</font><font size="3" color="#0000FF" face="serif"><u><br></u></font><a href="mailto:Cfp-interest@oakapple.net"><font size="3" color="#0000FF" face="serif"><u>Cfp-interest@oakapple.net</u></font></a><font size="3" color="#0000FF" face="serif"><u><br></u></font><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><font size="3" color="#0000FF" face="serif"><u>http://mailman.oakapple.net/mailman/listinfo/cfp-interest</u></font></a><p><font size="3" face="serif"><br><br><br></font></ul><br><BR>
<BR>
</body></html>