<html><body><p><font size="2" face="sans-serif">Hi Aaron,</font><br><br><font size="2" face="sans-serif">We discussed this in our CFP meeting today and I'd like to update you on what we discussed. While what I said in the last note was essentially true, I was remiss in mentioning that in TS18661-5 (which WG14 did NOT vote into C23), the FLT_EVAL_METHOD macro is actually not a constant in terms of being able to be used in #if and #elif preprocessing directives, and is intended to change to reflect the effective value as a result of the block level pragma "#pragma STDC FENV_FLT_EVAL_METHOD width".</font><br><br><font size="2" face="sans-serif">So if you do intend to at some point implement part 5 of the TS (Ex. if a later release of the C standard standardizes it and it needs to be implemented), then it does make sense to allow it to change values. Note that you do lose the #if/#elif use cases if you do this though.</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><br><img width="16" height="16" src="cid:1__=8FBB0DCCDFE410918f9e8a93df938690@ibm.com" border="0" alt="Inactive hide details for Rajan Bhakta---08/30/2021 03:50:04 PM---Hi Aaron, I am forwarding this question on to the CFP group ("><font size="2" color="#424282" face="sans-serif">Rajan Bhakta---08/30/2021 03:50:04 PM---Hi Aaron, I am forwarding this question on to the CFP group (cc'd on the list), but I can also give</font><br><br><font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Rajan Bhakta/Houston/IBM</font><br><font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"Aaron Ballman" <aaron@aaronballman.com></font><br><font size="1" color="#5F5F5F" face="sans-serif">Cc: </font><font size="1" face="sans-serif">cfp-interest@oakapple.net</font><br><font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">08/30/2021 03:50 PM</font><br><font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [EXTERNAL] CFP question with FLT_EVAL_METHOD</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><font size="2" face="sans-serif">Hi Aaron,</font><br><br><font size="2" face="sans-serif">I am forwarding this question on to the CFP group (cc'd on the list), but I can also give you my opinion of the intent right now as well.</font><br><br><font size="2" face="sans-serif">The FLT_EVAL_METHOD is intended to be a once per TU setting and it was expected that compile time flags or switches would change the value. In practice, we haven't seen an implementation really do that. Furthermore, in actual practice what we've heard is that a lot of implementations set it wrong (and would possibly be better served by the macro expanding to the value of -1).</font><br><br><font size="2" face="sans-serif">That being said, I don't think there is any real wording preventing a modification to the value via another pragma, just as there is not for many other macros like FLT_RADIX, and even non floating point related ones we traditionally consider TU level constants such as CHAR_BIT, INT_MAX, etc. i.e. Nothing special about FLT_EVAL_METHOD in this way.</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><br><br><img width="16" height="16" src="cid:1__=8FBB0DCCDFE410918f9e8a93df938690@ibm.com" border="0" alt="Inactive hide details for "Aaron Ballman" ---08/30/2021 01:57:39 PM---I ran into an implementation question with FLT_EVAL_METHO"><font size="2" color="#424282" face="sans-serif">"Aaron Ballman" ---08/30/2021 01:57:39 PM---I ran into an implementation question with FLT_EVAL_METHOD and I was wondering if I could pick your</font><br><br><font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">"Aaron Ballman" <aaron@aaronballman.com></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">08/30/2021 01:57 PM</font><br><font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">[EXTERNAL] CFP question with FLT_EVAL_METHOD</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">I ran into an implementation question with FLT_EVAL_METHOD and I was<br>wondering if I could pick your considerable brains on what you think<br>the right answer is. Imagine code like:<br><br>#include <stdio.h><br>#include <float.h><br><br>#ifdef ON<br>#pragma float_control(source, on, push)<br>#endif<br><br>int main() {<br> printf("FLT_EVAL_METHOD = %d\n", FLT_EVAL_METHOD);<br>}<br><br>Would you expect the FLT_EVAL_METHOD macro to expand to a different<br>value depending on whether ON is defined or not? We're trying to<br>figure out whether the standard requires FLT_EVAL_METHOD to report<br>back transitional values that may be under control of a #pragma, or<br>whether we have the latitude to decide to only report one value for<br>FLT_EVAL_METHOD for the entire TU.<br><br>Thanks!<br><br>~Aaron<br></font></tt><br><br><br><BR>
<BR>
</body></html>