[cfp-interest 3897] JTC1/SC22/WG14/CFP 2026/04/15 Meeting notes
Jerome Coonen
jcoonen at gmail.com
Fri Apr 17 10:23:36 PDT 2026
2026/04/15: 8:00 AM PDT/3:00 PM UTC
[Please submit proposed changes to these minutes to Jerome or to the group.
Revision changes appear at the bottom.]
*Attendees*
Jim Thomas, Rajan Bhakta, Jerome Coonen, Damian McGuckin, Joshua
Cranmer, Fred Tydeman, David Hough, Ariel Burton, Guy Davidson
*Updated agenda plus new items*
https://cfp-wiki.esi.com.au/pub/CFP/WebHome/CFP%20meeting%20agenda-20260415.pdf?_t=1776288481
–
These minutes should be read alongside the agenda, with its many reference
links.
*Previous meeting notes*
https://mailman.oakapple.net/pipermail/cfp-interest/2026-March/003840.html
2026/02/18 Meeting notes
*Study group logistics*
Next meeting: 13 May 2026, 8:00 AM PDT/3:00 PM UTC
ISO Zoom teleconference
Please notify the group if this time slot does not work.
*C documents*
The latest C2Y draft is N3854 Mar. 2026
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3854.pdf
C23 has been published ISO/IEC 9899, available for purchase.
https://www.iso.org/standard/82075.html
*IEEE 754 liaison*
David: Still moving very slowly. Many new ideas, some not upward
compatible.
Damian: Has been voted official 754 liaison to WG14.
*C++ liaison*
Joshua: Has had committee meeting. Will rebase C++26 on C23. Discussion
continues on the proposals listed in the March CFP minutes. Some topics:
working on spelling of the functions like "fadd", that produce a narrower
result (http://wg21.link/P3935); subtleties with literal expressions (
http://wg21.link/P3938); the paper about naming correctly-rounded functions
is withdrawn, pending further study; finally, the committee is looking at
adopting Annex F bindings to 60559.
*WG14 update*
Rajan: Next meeting, Ottawa, 17-21 August. Last meeting, approved a new
wording study group. It is available for advice on proposals in
development, and will provide review of the language of proposals approved
by WG14.
Jim: Will there be written recommendations from the group, like a study
guide? It might be good for Damian to connect with group about the major
Annex F update.
Rajan: There is no stated plan for the study group to write guidelines.
*TS-4 and TS-5 revisions*
None
*News*
None
*Carryover action items from last meeting *
Group: Think about where CFP is headed.
Discussion
Jerome & Damian: Write a proposal to repair fromfp and enhance Table
F.2.
Done
*Action items from last meeting *
Jim: Add agenda item to fix range bounds problem for complex fcns (as
done for real functions in N3731).
Done
Jerome: Research usage of "occur(s)" and how it applies to proposal
n3737.
Done
Jim: Submit double_t proposal.
Done, n3843
Damian: In the Annex F special cases paper, add the function header to
the code examples (which will clarify the usage of the parameters).
Done
Jim & Damian: Review the wording of F.10.4.7 and F.10.4.9 and propose
any changes.
Done
Damian: Update the Annex F Special Cases paper as technical plus
editorial.
Done
Damian & Jerome: Send a note to CFP about the usage of "current
rounding direction".
Done
Damian: Draft a proposal for a new table (F.3) in Annex F mapping the
rounding direction attributes from 60559 to the language of C2Y.
Done
*Discussion of issues*
Annex F table numbering
Damian: We noticed that there is no Table F.1, leading to potential
naming issues if current table names are shifted down one. Also an error
slipped into C2Y, where an editorial change led to a typo. Table F.3 became
F.2 in F.10.1#16.
Rajan: Suggests note to JeanHeyd to fix. No need for a paper.
Sign of zero from fromfp functions
Jerome: Discusses the proposal, after much wordsmithing with Jim,
based on prior discussions around the need to specify the sign of
(floating) zero results in fromfp. Because this change fills a gap in the
specification, there is the chance to break an existing implementation. (a)
Given that the next step after fromfp is to convert to an integer format
unlikely to support signed zero, this specification is unlikely to be
noticed. (b) As Rajan has pointed out, in such instances WG14 prefers a
complete specification over undefined results.
Group: Submit to WG14. Action.
Range bounds problem for complex fcns
Jim: This fix is a request from WG14. A correctly rounded
implementation might round a result outside the a mathematical bound such
as pi, which lies between representable floating values. This was fixed in
the real domain but the problem arises for complex functions, too. The
changes in the wording emphasize the mathematical range, apart from the
representable result values. A NOTE illustrates the issue, but is not
repeated in every instance.
Jim & Rajan: Typo: "arc sine" in the Description should be "arc
cosine".
Group: Write a proposal. Action
Usage of "occur(s)" with regard to proposal n3737
Jerome: Summarizes the review of 420 instances of "occur",
concluding that the usage in n3737 is consistent with C2Y as a whole.
Annex F special cases
Damian: Takes a summary pass through the special cases in Annex F.
Describes the locution for the trickiest cases, such as "all values,
including NaN". The only mention of signaling NaN is when it is
specifically included in a specification, such as for fabs.
Jim: The use of "forgotten" in the discussion when some connection
or specification has been "omitted" is not best.
Jim: Discusses item (c) in the "Inconsistencies" discussion. When
an italicized parameter x is used, it refers to the value passed to the
function.
Fred: Distinguishes "argument" -- the expression whose value is to
be passed to a function -- from "parameter" -- the declared object in
function receiving the argument value.
Jim, Fred, et al.: The subtlety is whatever conversion might be
required to match the argument value to the parameter type.
Damian: Discusses the modf (thanks, Fred) and scalbn special cases.
Jim & Rajan: We need to emphasize the technical changes for WG14.
Suggest references to the changes early in the document, with some
elaboration from current content.
Damian: Notes changes to replace the unfortunate name "value" as a
parameter. Notes that code examples have been expanded to include a full
function definition and to explicitly mention FENV_ACCESS when needed.
Damian: Uses "result" consistently, where a mix of "result",
"return value", and even "return" appear.
Group: This attention to the language in Annex F is consistent with
the mission of the WG14 wording study group.
Damian: Notes the change to the ldexp comment, that now applies to
all radixes.
Fred & Joshua: Returning to the argument/parameter theme, present a
vintage 32-bit x86 sidebar. With 80-bit floating stack on 80x87 math
processors, the API states that floating values are passed in memory
while results are returned on the 80-bit stack. SThe means signaling nans
can be passed as arguments without triggering a change to a quiet version.
Group: A quick review of totalorder led to the simplification to
stick to the wording needed for Annex and defer the specifics of the
function to a simple reference, via language like, "For the detailed spec.."
Action to revise the paper, converging toward a proposal.
Rounding terminology
Damian: Reviews the detailed email of dozens of instances, mostly
in Section 7, that need repair. The discussion of the language issues is in
the rationale of the Annex F proposal.
Jim: This large set of small changes needs a volunteer. Carry over
Fixes to symbols: minus signs and hyphens, etc.
Jim: Discusses his paper on editorial changes to F.9.3 and F.9.4.
What used to be C symbols became mathematical symbols during an edit. This
came as a surprise. But the context is beyond the level of C expressions
and into mathematical transformations within the compiler. The
typography is correct, because it is mathematical computations that are
being transformed, not C expressions.
Jim: Suggests changing the first sentence in F.9.3 #2 to “The
discussion of transformations in this subclause applies to computations
involving standard floating types.”
Jerome et al.: Given that it's computations not expressions that
are being transformed, the section name "Expression transformations" is
inappropriate and needs to be changed, perhaps to "Computation
transformations".
Jim: Another issue is that "true" and "false" are used where 1 and
0 would be more appropriate because the operator is computing a value of
type int, not bool.
Jim: Carry over
CFP future
Jim: Announces that he is retiring from CFP. Has been chair sInce
the first meeting in Sept 2009. Expresses appreciation of all the support
throughout CFP and WG14. Rajan is taking over as CFP chair. He's been,
"outstandingly effective with WG14." This all started with NCEG (Numerical
C Extensions Group), a 10 year effort to reach C99.
Fred: The first NCEG meeting was in 1991.
David: Rex Jaeschke was the first convener, now at a higher level.
NCEG was broader then. Rex's web page explains some history.
Rajan: Got his own start with 754-2008 binding. Then on to 754-2019.
*Other issues*
None
*Adjournment*
10:00 AM PDT
-----------------------------------------------
*Action items to be carried over*
Group: Think about where CFP is headed
*New action items*
Jerome: Submit the fromfp paper.
Rajan & Jerome: Write a proposal to fix complex range bounds.
Damian: Update Annex F proposal for discussion at next meeting.
*Carryover discussion items*
Rounding terminology
Fixes to symbols: minus signs and hyphens, etc.
Complex and signaling NaNs
INFINITY and _Float16
Annex F 2.2, 3.0, 10.1
*Signoff*
Respectfully submitted.
-Jerome Coonen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20260417/786e87ac/attachment-0001.htm>
More information about the cfp-interest
mailing list