C language update puts backward compatibility first

A working draft of the standard for the next revision of the C programming language, referred to for now as “C2x,” is now available for review.

Most of the changes thus far approved for C2x don’t involve adding new features, but instead clarify and refine how C should behave in different implementations and with regard to its bigger brother C++. The emphasis on refinement is in line with how previous revisions to C—C11 and most recently C17—have unfolded. 

As described in the C2x Charter, the plan strongly emphasizes keeping future editions of the language compatible with the large body of existing C code, and to avoid (although not totally rule out) “quiet changes” or changes “that cause a working program to work differently without notice.”

WG14, the group that oversees the development of the C standard (ISO/IEC 9899), has so far formally approved only a small number of changes to the language from the C17 standard. Some of the most notable changes accepted so far:

• A clarification of the restrict keyword. The restrict keyword is used to inform the compiler that a given object in memory can only be accessed by that pointer, as an optimization. In C2x, there will be more detailed examples of how restrict ought to behave, the better to ensure compilers don’t end up making unsafe or unnecessary optimizations.
• Making static_assert behave the same in C as it does in C++. The static_assert declaration, found in both C and C++, is used to ensure that a given constant expression is valid at compile time, but it is implemented differently in the two languages. With this change, the C2x version will behave the same as the C++ version, making it easier to share header code between the languages and to translate between C and C++.
• Better definitions for behavior of unions. Different implementations of C have different behavior when it comes to anonymous unions, a feature added in C11. C2x clarifies how this works so it’s not dependent on the implementation.

Other changes include how to handle divide-by-zero cases in pow(), evaluation formats for floating points, and more clarification on dealing with wide-character encoding conversions.

C is the foundation for many popular software projects such as the Linux kernel and it remains a widely used language, currently second in the Tiobe index. Its simplicity makes it a common choice for software applications that run at or close to bare metal, but developers must take extra care in C, versus higher-level languages like Python, to ensure that memory is managed correctly—easily the most common problem found in C programs.

Previous revisions to the C standard added features to help with memory management—including the “Annex K” bounds-checking feature. However, one of the proposals on the table for C2x is to deprecate or remove the Annex K APIs, because their in-the-field implementations are largely incomplete, non-conformant, and non-portable. Alternative proposals include replacing these APIs with third-party bounds-checking systems like Valgrind or the Intel Pointer Checker, introducing refinements to the memory model, or adding new ways to perform bounds checking for memory objects.

Aside from revisions to the official C standard, other projects have bubbled up to offer better ways to write C. Microsoft’s Checked C extension adds checks to prevent many common errors with memory handling. Jens Gustedt, a core contributor to the C standard, has his own Modular C proposal that gives C a module system akin to those found in higher-level languages. 

The current roadmap for C2x provides at least two more years for the proposals to shake out. WG14 is aiming for “a revised standard by the end of 2021, with a publication date of 2022.”