<html><body><p><font size="2" face="sans-serif"> </font><font size="2" face="sans-serif"><b>Attendees</b></font><font size="2" face="sans-serif">: Rajan, Jim, Damian, Fred, David H., Mike, </font><br><br><font size="2" face="sans-serif"><b> New agenda items (</b></font><a href="https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20220210-update.pdf"><font size="2" face="sans-serif"><b>https://wiki.edg.com/pub/CFP/WebHome/CFP_meeting_agenda_20220210-update.pdf</b></font></a><font size="2" face="sans-serif"><b>):</b></font><br><font size="2" face="sans-serif"> Paul Zimmerman's email CFP2370.</font><br><font size="2" face="sans-serif"> Fred: What about adding an 'i' suffix for imaginary (posted in WG14's reflector).</font><br><br><font size="2" face="sans-serif"><b> Next Meeting(s):</b></font><br><font size="2" face="sans-serif"> March 16th, 2022, 3PM UTC (8am Pacific time expected due to Daylight Saving Time in parts of USA)</font><br><font size="2" face="sans-serif"> ISO Zoom teleconference</font><br><font size="2" face="sans-serif"> Please notify the group if this time slot does not work.</font><br><br><font size="2" face="sans-serif"> Mike: Will be unavailable then. +/- a week each way as well.</font><br><br><font size="2" face="sans-serif"><b> WG14 meeting:</b></font><br><font size="2" face="sans-serif"> See CFP2366, CFP2361-CFP2363, CFP2367</font><br><font size="2" face="sans-serif"> N2860: No reservation of math function names as external identifiers. Not everyone has a separate math library.</font><br><font size="2" face="sans-serif"> David H: I agree that it is not good to split the C library.</font><br><font size="2" face="sans-serif"> Jim: My first reaction is negative with it. C code could have these identifiers mean anything on other implementations. It's selling problems.</font><br><font size="2" face="sans-serif"> Fred: A lot of implementations have libm. Jen's basic issue is the addition of so many identifiers. He doesn't like it. I believe Jens proposal to make true/false identifiers will break more things than all of the math stuff.</font><br><font size="2" face="sans-serif"> Jim: The identifiers in math.h are reserved right now externally?</font><br><font size="2" face="sans-serif"> Rajan: Yes. Still a portability concern if they use the name for something else. Ex. cos could be used for something else.</font><br><font size="2" face="sans-serif"> Damian: How many things is this going to break? Currently neutral.</font><br><font size="2" face="sans-serif"> Jim: About breaking more things in the future, Jens concern is more a constraint on programming due to reduced user namespace. I believe the only objections have been from Jens, none from users. There are implementations out there and no user issues.</font><br><font size="2" face="sans-serif"> Fred: Only POSIX and gamma had a namespace issue in the past which is why we came up with tgamma.</font><br><font size="2" face="sans-serif"> N2887: Example using sqrt as an unsequenced function.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"><b> C++ Liaison:</b></font><br><font size="2" face="sans-serif"> Nothing new.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"><b> C23 Integration:</b></font><br><font size="2" face="sans-serif"> Review draft: See CFP2320</font><br><font size="2" face="sans-serif"> Discussion under CFP2319 and follow ups.</font><br><font size="2" face="sans-serif"> Jim: The annex is worrisome since it is a big annex.</font><br><br><font size="2" face="sans-serif"><b> Carry-over action items:</b></font><br><font size="2" face="sans-serif"> Fred: Ask C++ what their issues with *_HAS_SUBNORM are and if they are OK with obsoleting it. - Still open</font><br><font size="2" face="sans-serif"> Fred: Their numeric study group has not looked at it yet still.</font><br><font size="2" face="sans-serif"> Jim: Did WG14 want it removed?</font><br><font size="2" face="sans-serif"> Fred: No, they definitely did not agree to that.</font><br><font size="2" face="sans-serif"> Jim: Then what did they approve?</font><br><font size="2" face="sans-serif"> Rajan: The implementation defined meaning of the macro and operations/operators.</font><br><font size="2" face="sans-serif"> Jim: Track the many changes to infinity and nan macros. Particularly still need to check prefixes for signaling nan macros. - Done.</font><br><font size="2" face="sans-serif"> Jim: Sent in the changes. New changes based on those will need to be reviewed again. Can close the item.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"><b> Last meeting action items (done unless specified otherwise, details below):</b></font><br><font size="2" face="sans-serif"> Rajan: Update CFP2341 to use paragraph form with semicolon separators.</font><br><font size="2" face="sans-serif"> Rajan: CFP2341: Look into seeing if we can say errno and the floating point environment can't be accessed (like with the "as if" rule).</font><br><font size="2" face="sans-serif"> Rajan: Update CFP2341 to say the identifiers for fenv.h and math.h should also be reserved as per stdlib.h in alternative 1.</font><br><font size="2" face="sans-serif"> Fred: Post the list of issues to be revisited for the next version on the CFP wiki.</font><br><font size="2" face="sans-serif"> Fred: Add an issue for a future version to look at the 5.2.4.2.2 terminology and ensure it is correct and consistent.</font><br><font size="2" face="sans-serif"> Fred: Put the NAN not raising exceptions footnote idea into the list of items for a future revision of C.</font><br><br><font size="2" face="sans-serif"><b> New action items:</b></font><br><font size="2" face="sans-serif"> Fred: Expand the individual items so they are self contained in C26.TXT.</font><br><font size="2" face="sans-serif"> Fred: Ensure that CFP2350 was sent to the C editor.</font><br><font size="2" face="sans-serif"> Jim: Respond to Vincent's CFP2368 message regarding the floating-point model.</font><br><font size="2" face="sans-serif"> Jim: Reply to CFP2371 saying it is in the Annex we proposed and WG14 voted in.</font><br><br><font size="2" face="sans-serif"><b> Upcoming WG14 meetings:</b></font><br><font size="2" face="sans-serif"> January 31-February 18 - Ongoing right now (one week meeting, one week off, one week meeting)</font><br><font size="2" face="sans-serif"> May 16-20 virtual</font><br><font size="2" face="sans-serif"> July 18-22 virtual</font><br><br><font size="2" face="sans-serif"><b> Action item resolutions:</b></font><br><font size="2" face="sans-serif"> Rajan: Update CFP2341 to use paragraph form with semicolon separators.</font><br><font size="2" face="sans-serif"> Rajan: CFP2341: Look into seeing if we can say errno and the floating point environment can't be accessed (like with the "as if" rule).</font><br><font size="2" face="sans-serif"> Rajan: Update CFP2341 to say the identifiers for fenv.h and math.h should also be reserved as per stdlib.h in alternative 1.</font><br><font size="2" face="sans-serif"> See CFP2346 and follow-ups.</font><br><font size="2" face="sans-serif"> Jim: The wording issues with parallelism and all was cleaned up well. But the various alternatives are really different things. There is no issue really so it is on the C++ side or Josephs side to bring up why they believe that locales or errno are an issue. For the floating point environment, the FENV_ACCESS pragma needs it's state to be ON before it can access the modes. If we say freestanding has it OFF or does not turn it on, it handles that aspect. The allowing math_errhandling to be zero is a worthwhile convenience that is independent. I believe it was an oversight on our part to not give the option for exceptions for the conversion functions.</font><br><font size="2" face="sans-serif"> Fred: Prefer Jim's method.</font><br><font size="2" face="sans-serif"> Rajan: Will go forward with Jim's method.</font><br><font size="2" face="sans-serif"> Jim: The footnotes seem to be implementation guidance. That is something the C standard does right?</font><br><font size="2" face="sans-serif"> Rajan: Yes.</font><br><font size="2" face="sans-serif"> Jim: Don't understand inclusive/exclusive and alternatives.</font><br><font size="2" face="sans-serif"> Rajan: That will go away with the new wording.</font><br><br><font size="2" face="sans-serif"> Fred: Post the list of issues to be revisited for the next version on the CFP wiki.</font><br><font size="2" face="sans-serif"> Fred: It is on the wiki: C26.TXT (</font><a href="https://wiki.edg.com/pub/CFP/WebHome/C26.TXT"><font size="2" face="sans-serif">https://wiki.edg.com/pub/CFP/WebHome/C26.TXT</font></a><font size="2" face="sans-serif">)</font><br><font size="2" face="sans-serif"> Damian: Which directory is it in?</font><br><font size="2" face="sans-serif"> Fred: As far as I know, there is only one directory in the wiki.</font><br><font size="2" face="sans-serif"> Jim: Is saying the document number good enough for things like the CFP2256 item.</font><br><font size="2" face="sans-serif"> Fred: I can write it out.</font><br><font size="2" face="sans-serif"> ^Fred: Expand the individual items so they are self contained in C26.TXT.</font><br><br><font size="2" face="sans-serif"> Fred: Add an issue for a future version to look at the 5.2.4.2.2 terminology and ensure it is correct and consistent.</font><br><font size="2" face="sans-serif"> In the C26.txt file on the wiki.</font><br><br><font size="2" face="sans-serif"> Fred: Put the NAN not raising exceptions footnote idea into the list of items for a future revision of C.</font><br><font size="2" face="sans-serif"> In the C26.txt file on the wiki.</font><br><br><font size="2" face="sans-serif"><b> Other issues:</b></font><br><font size="2" face="sans-serif"> Terminology: floating constant vs floating-point constant (See CFP 2345,2349,2350)</font><br><font size="2" face="sans-serif"> Jim: Did you send CFP2350 to the editor?</font><br><font size="2" face="sans-serif"> Fred: I need to check. I believe I did.</font><br><font size="2" face="sans-serif"> Jim: Can you double check?</font><br><font size="2" face="sans-serif"> ^Fred: Ensure that CFP2350 was sent to the C editor.</font><br><font size="2" face="sans-serif"> Damian: So we should use "floating constant" now in our documents?</font><br><font size="2" face="sans-serif"> Jim: Yes. It is a term in the C standard, not the general English term.</font><br><br><font size="2" face="sans-serif"> Subnormals and infinities (See CFP2368)</font><br><font size="2" face="sans-serif"> Jim: A C object representation that has a bit pattern that is a 754 subnormal need not be a C subnormal. An implementation can make all 754 subnormals as zero's.</font><br><font size="2" face="sans-serif"> Mike: Even for decimal?</font><br><font size="2" face="sans-serif"> Jim: No, since that has to follow IEEE.</font><br><font size="2" face="sans-serif"> David H: It's a little odd, but a reflection of reality. To change that would mean invalidating some implementations.</font><br><font size="2" face="sans-serif"> Jim: Right.</font><br><font size="2" face="sans-serif"> Jim: For the -infinity part, C does have "<" results in 1 if the relation is true. It doesn't explicitly say 1<2 just like it doesn't say 1 < infinity.</font><br><font size="2" face="sans-serif"> Fred: The C standard does say if -infinity is there the range is extended to all negative numbers. Ditto for positive.</font><br><font size="2" face="sans-serif"> Jim: I think that is consistent with it. The range type is a specific term used in a specific way. I am not sure he would agree that this says this. I don't think we need to say anything here. It is complete just as it is for real numbers.</font><br><font size="2" face="sans-serif"> ^Jim: Respond to Vincent's CFP2368 message regarding the floating-point model.</font><br><font size="2" face="sans-serif"> David H: Does C allow an unsigned infinity?</font><br><font size="2" face="sans-serif"> Jim: It does.</font><br><font size="2" face="sans-serif"> David H: In the original 754, it was unordered.</font><br><font size="2" face="sans-serif"> Mike: Like NAN.</font><br><font size="2" face="sans-serif"> David H: Exactly.</font><br><font size="2" face="sans-serif"> Damian: How do you get one?!</font><br><font size="2" face="sans-serif"> David H: It was added. It wasn't IEEE.</font><br><font size="2" face="sans-serif"> Jim: Do implementations have unsigned infinity?</font><br><font size="2" face="sans-serif"> David: I've never heard of any.</font><br><font size="2" face="sans-serif"> Mike: You can ask Vincent if he knows any.</font><br><font size="2" face="sans-serif"> (Mike dropped off)</font><br><br><font size="2" face="sans-serif"><b> Others (new items added to the agenda):</b></font><br><font size="2" face="sans-serif"> See CFP2371.</font><br><font size="2" face="sans-serif"> Rajan: All we need to say is that it's been voted in and it'll be there when it is there.</font><br><font size="2" face="sans-serif"> ^Jim: Reply to CFP2371 saying it is in the Annex we proposed and WG14 voted in.</font><br><font size="2" face="sans-serif"> </font><br><font size="2" face="sans-serif"> Using the 'i' suffix for imaginary numbers:</font><br><font size="2" face="sans-serif"> Fred: A user, but not a standards member asked for the i suffix for an imaginary floating constant. I don't know if it is something we can get into C23.</font><br><font size="2" face="sans-serif"> Rajan: We've missed the cutoff.</font><br><font size="2" face="sans-serif"> Jim: Not critical or an IEEE-754 binding issue.</font><br><font size="2" face="sans-serif"> Fred: I'm in favor of adding it. Multiplying by 'I' is not always the cleanest way to do things.</font><br><font size="2" face="sans-serif"> Jim: Trying to think why we didn't consider this. Probably because we didn't want to change the language.</font><br><font size="2" face="sans-serif"> Fred: Imaginary is not required.</font><BR>
<BR>
</body></html>