Overview
The week of April 3, I attended a meeting of WG14, the C standardization committee, in Markham, ON. Markham is a suburb of Toronto about 40 minutes drive north. Unlike Toronto itself, it's not a particularly interesting destination. We had four days of rain followed by snow, freezing temperatures, and the wind, which was perfect for spending time indoors and made it easy to resist any temptation to go sightseeing.
Location
The meeting was hosted by IBM at their Toronto Software Lab, which, despite its name, is located in Markham and not Toronto. The lab is a complex of several attached buildings with a capacity of about 2,500 employees (they're about 80% full). Our host was nice enough to give us a presentation on interacting with the IBM z System operating environments, followed by a tour of the computing center, the largest in Canada in terms of sheer computing power.
Participation
The meeting was attended by about 20 people in the room and as many as three on the phone at various times, representing CERT, Cisco, GrammaTech, IBM, INRIA, LDRA, LLNL, Oracle, Perennial, Plum Hall, Red Hat, Siemens, and a number of small consultancies hailing from Canada, Norway, France, the UK, and of course the US.
Objectives
The main objectives of the meeting were to finalize the 2017 "Technical Corrigendum" of C11 and make more progress toward C2X. I put "Technical Corrigendum" in quotes because due to ISO restrictions it won't really be a TC but a whole new standard, albeit one restricted to TC changes, with only bug fixes and no technical changes, meaning no new features.
Defect Report Processing
Over the course of four days, we reviewed open defect reports, closed those that were ready to be closed, and spent hours debating the process that the remaining and any new defects will follow going forward. We spent, even more, hours discussing a few C11 defects that some of us felt should be fixed in the 2017 TC but that could only be solved by technical (i.e., substantive) changes as opposed to simple clarifications. As an extreme example, it took us a good couple of hours over two days to get comfortable with the removal of three words (with no impact whatsoever no existing implementations or programs) as the resolution for DR 485. The pre-meeting state of C11 defect reports is in document N2109. The final state will be published in a post-meeting mailing in a few weeks.
Other Papers
We also heard a presentation from the LLNL representative who shared some serious concerns with the CPLEX specification that is up for renewal. The issue is with the interoperability of CPLEX code with other code written to other APIs (such as C11 Threads, Pthreads, or OpenMP). See N2131 for more. In light of the concerns and their gravity, the chair of the CPLEX study group, Clark Nelson, was tasked with providing guidance to WG14 as to how to address them. According to Clark, the CPLEX study group has been largely inactive the last 6 months to a year making it uncertain what that will mean for the future of the spec.
C2X Proposal Review
Besides defect processing, we also discussed a relatively modest number of proposals for C2X features and spent some time reviewing the C standard after it has been migrated to LaTeX. The new document is quite nice and takes greater advantage of modern features like linking and even colors.
Floating-Point Proposals
With a few minor exceptions, the remaining papers were focused on proposing to incorporate portions of TS 18661 — Floating-point extensions for C.
N2117: TS 18661-3 - interchange and extended types. Proposes to add the ISO 60559-recommended interchange and extended floating-point types like GCC's _FloatN and _FloatNx.
N2118 and N2119: TS 18661-4 — mathematical and reduction functions. A pair of proposals to incorporate a number of functions to support mathematical operations recommended by the current IEC 60559, such as exp10 and rsqrt.
N2120, N2121, N2122, and N2123: TS 18661-5 — evaluation format pragmas, optimization control pragmas, reproducible results, and alternate exception handling. Papers proposing to add knobs in the form of pragmas to control various fine aspects of evaluating floating point expressions as recommended by ISO 60559. Of these, the last one proved to be somewhat controversial due to both the out-of-band approach to intercepting floating point exceptions, and the interaction of the pragmas with surrounding code. The intent of pragmas is that implementations be able to ignore those they don't implement, with no impact on the correctness of a program. The pragmas introduced by the last proposal would go against that intent.
Other Proposals
Besides the floating point proposals, a couple of other papers presented to the committee that is worth mentioning are:
N2101: __has_include for C. The paper proposes to add the C++ __has_include trait to C2X to make it possible to determine whether the named header exists. The group was in favor of adopting this feature in C2X.
N2129: Deprecate __LINE__. The paper identifies a surprising problem with the __LINE__ macro and proposes to replace it with a couple of others that are safer to use. The proposal was nearly unanimously rejected due to the prevalence of the macro in existing code.
Future Meetings
The next meeting is tentatively scheduled for the first week of November, in Albuquerque, NM. With C 2017 finalized, WG14 will focus all its resources on C2X. If you have thoughts or suggestions for enhancements to the language, this is the perfect time to write them up and submit them either to a representative from your organization or your national body representative for the October mailing.
The following meeting after that will take place in April 2018 and be hosted by the Red Hat Brno office in the Czech Republic.
Developers can now get a no-cost Red Hat Enterprise Linux® Developer Suite subscription for development purposes by registering and downloading through developers.redhat.com.
Last updated: September 19, 2023