Trip Report: October 2016 WG14 Meeting
In October 2016, I attended the WG14 (C language committee) meeting in Pittsburgh, Pennsylvania. The meeting was hosted by the Computer Emergency Response Team (CERT) at the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU). We had 25 representatives from 18 organizations in attendance, including CERT, Cisco, IBM, INRIA, Intel, LDRA, Oracle, Perennial, Plum Hall, Siemens, and the University of Cambridge. It was a productive four days spent on two major areas:
- Work on C11 defect reports aimed at the upcoming C11 Technical Corrigendum (TC) expected to be finalized in 2017. This will be the last revision of C11 to be published. The next revision of C will be a "major" version that is for the time being referred to as C2X.
- Review of proposals for the next revision of C, C2X. To meet the TC 2017 schedule some C11 defects will have to be deferred to C2X. The C2X charter is in N2086.
Below is a list of some of the interesting C2X proposals the group discussed.
Attributes for C
This proposal consists of five papers. The first introduces the general framework and syntax for attributes and the rest propose the four attributes for inclusion in C2X.
- N2049 — Attributes in C
- N2050; — The deprecated attribute
- N2051; — The nodiscard attribute
- N2052; — The fallthrough attribute
- N2053; — The maybe_unused attribute
The five papers collectively propose to add the C++ attribute syntax (e.g., [[deprecated "Don't use this"]]) to C and to add the attributes deprecated, nodiscard, fallthrough, and maybe_unused. All four attributes are part of C++ 17 and supported by recent C++ (and, as extensions, some C) compilers, including GCC.
A number of attendees didn't care for the C++ [[attribute]] notation and suggested more appealing alternatives such as the widely established GCC syntax __attribute__((name)). However, since one of the major motivators for the proposal is improving interoperability with C++, adopting a different syntax would go against that goal. Although the question of syntax remains to be decided there was fairly strong support for the individual attributes themselves.
Extending Integer Constant Expressions
N2067 — The Register Overhaul, is a proposal to enhance C to require implementations to treat more integer expressions as constant, including array elements. The proposal repurposes the register keyword to achieve this in a backward compatible way. For example, the following declares a constant array of 42 elements that would have to be fully evaluated at compile-time and usable in other constant integer expressions such as enumerators.
register const int nelems = 42;
register const int array[nelems] = { 1, 2, ... };
enum { e = array[7] };
There was a consensus among the attendees that WG14 wants to extend constant integer expressions but the idea of using the register keyword was not embraced. A number of members argued that the same can and should be achieved without a new keyword (though for backward compatibility C would require programs to use static const). The proposal also suggests applying register to inline functions in order to let them use static constants (referring to static objects in C11 inline functions as undefined).
Const-Correct Overloads of String Functions
N2068 — Type Generic String Interface, proposes to add a new header named <tgstring> with const-correct "overloads" of string manipulation functions like memchr and strchr analogous to those in C++. The proposal goes farther than C++ did and suggests adding a const overload for strtod.
double strtod (const char*, char const **)
The proposal also provides an additional set of overloads for the wide character functions (under the same names as the narrow character equivalents). The proposal expects implementations to rely on the C _Generic facility to achieve the overloading but doesn't prevent them from using other mechanisms. A portable implementation of the header using _Generic is provided for reference.
Feature Test Macros for New C Features
N2069 — Mandatory C Library Headers. This paper proposes to require all implementations (including freestanding) to provide all library headers and define a macro in each indicating whether the contents of the header conform. The goal is to make it easier to port code to new and not yet complete implementations of new or upcoming standards. The feature is based on the assumption that the first thing library implementers will do when setting out to provide support for the next standard is create all the new headers (even empty) and define the new macros. The C++ __has_include preprocessor operator was brought up during the discussion of this proposal as complementary.
Add TS 18661-1 and TS 18661-2 to C2X
N2078 and N2079 are a pair of proposals to incorporate parts 1 and 2 of ISO/IEC TS 18661 — Floating-Point Extensions for C, into C2X. Technical Specification 18661 brings C up to date with the latest ISO/IEC 60559:2011 — Floating-Point Arithmetic standard. Part 1 of the TS outlines support for Binary floating-point arithmetic, and part 2 Decimal floating-point arithmetic. There was almost unanimous consensus within WG14 that this is important and there is a good chance that the proposal will be accepted. The remaining parts of TS 18661 are expected to be proposed for inclusion in C2X in the future.
Array Sections
N2081 — Array sections for C, is a fairly ambitious proposal to add the equivalent of FORTRAN array sections to C. As an example, the following statement would transpose row 0, columns 0-9 of array A, into column 0, rows 0-9 of array B.
B[0:10][0] = A[0][0:10];
The proposal also adds Reduction Operations under a novel syntax (similar in concept to C++ member functions but far less general. There was interest within WG14 in the basic part of the feature but an unease about the reductions.
Unspecified Values, Pointer Provenance, and Trap Representations
N2089 — Clarifying Unspecified Values, N2090 — Clarifying Pointer Provenance, and N2091 — Clarifying Trap Representations, are a trio of informal proposals from Peter Sewell's group at the University of Cambridge to formalize, clarify, and clean up the C specification of the three topics. The thrust of the proposals is to formalize what the C standard is thought to already require and what compiler writers have with some effort (and a bit of guesswork) mostly, though not entirely universally, converged on. The main objectives are to help programmers better reason about their code and to help compiler writers understand what is actually required (and what isn't). There is a good chance that the clarification could open up additional optimization opportunities. The group was impressed with these papers and generally in favor of proceeding in this direction. More work remains on the proposals to resolve a number of outstanding issues and questions.
Future Meetings
The next WG14 meeting is scheduled for April 2017, in Markham, ON, and will be hosted by IBM. After finalizing the 2017 Technical Corrigendum the committee is expected to devote most of its time to C2X. Those interested in learning more about the committee's work are encouraged to visit the group's website at WG14. If you would like to actively participate in the standardization process either contact your national body representative or ask for guidance on comp.std.c.
As a C/C++ developer, you want to be able to easily access and use supported versions of the latest and greatest tools, and you want to be able to get the most from those tools.
Last updated: February 26, 2024