C17 is a “bugfix release” of the C standard. Whereas the intention of the C working group (WG14) has been that this release does not introduce normative changes (but one), it brings a lot of clarifications all over the place. By adopting this version, some features as implemented by some compilers may change if their interpretation of C11 was different because of an unfortunate ambiguity.
C17 will be superseded by C2x, for which the process of inclusion has begun on the October 2018 of WG14. In particular, a working draft of C2x is now available that is still pretty close to C17:
C2x working draft, post October 2018 meeting
The schedule for C17 was as follows:
- Nov. 2017, adoption by WG14, subject to some minor, editorial changes
- Dec. 2017, integration of these changes and approval by an editorial committee
- Jan. to Mar. 2018, editorial back and forth with ISO, more editorial changes due to new requirements by ISO and their strict enforcement
- Apr 2018, ISO sends out the FDIS (final draft international standard) to the national bodies.
- Apr to June 2018, ballot
- June or July 2018, publication, see C17
I identified the following list of changes in C17 compared to C11. The whole process of clarifications that have been integrated is transparently documented in what we called “defect reports”. So if you urgently need to know about some of these you should look them up, there.
My intention is to write a post on most of the items to explain my POV of what happened. In particular, I will try to cite the new versions of the changed text for reference. Because of copyright issues, I will only be able to do that once C17 has been published by ISO. So please be patient and stay tuned.
- atomics: initialization (7.17.2, 7.31.8), coherence requirements (220.127.116.11), fences (7.17.3 p11), functions or macros (7.17.1 p6), lockfree depends on type (7.17.5 p3), compare exchange compares memory and not value (18.104.22.168),
- threads: spurious failures (22.214.171.124 p2, 126.96.36.199 p2, 188.8.131.52 p3), synchronization (7.26.4 p1), thread specific storage (
tss_t) and thread exit (7.26.5 p3, 184.108.40.206, 7.26.6)
_Generic (220.127.116.11), rvalues and qualification, cast (6.5.4)
- alignment: fundamental alignment (6.2.8),
- sequence points: full expressions (6.8 p4), full declarators (6.7..6 p3)
- infinite loops (6.8.5 p6)
- reserved identifiers (7.1.3)
- domain or range errors (7.12.1),
- underspecification of
- underspecification of
realloc for size 0 (18.104.22.168)
- Annex F:
FLT_ROUNDS (F.2 p1)
- Annex K:
NB: comments are switched off for this post. Please communicate errors or imprecisions that you spotted to me directly. If on the other hand you want to discuss the future (or not) of C, there are a lot of places out there. The best that I know of is WG14 itself. So if you really care, please sign in on your committee of your national standards body for programming languages or alike, and invest yourself in the process.
As you know, C and C++ are sister languages that have a lot in common, but that drifted quite apart over the years. In general, neither code of one language can be compiled as the other language, there are too many major and minor twists that make this impossible. Not only are there syntax differences between the two, some common syntax can actually have diverging semantics. So generally, it makes no sense to compile C code with a C++ compiler, and you should look with suspicion at any code or programmer that claims to do so.
Where C and C++ usually agree, though, is on the ABI, the application binary interface, so data structures and functions of one language can be used by the other to some extent. C and C++ also kept a sufficiently wide intersection in there respective specification of interfaces, such that one header file can be used from both.
In this post I try collect those parts that are in that intersection, and I propose some coding style that should accommodate both worlds suitably well. But as my personal history goes, this will merely be a POV of a C programmer that wants to provide interfaces for C++.
Continue reading “cross-language interfaces between C and C++”
When compiling position independent code, PIC, the gcc compiler fails to inline many functions that have an external name, that is that are not declared
static. While this is conforming to the C standard, this is a complete blow to a lot of optimization efforts that I have put into my code in many places.
Continue reading “gcc doesn’t inline position independent code properly”
C11 has added a certain level of Unicode support to C, but I think for C2x it will be time to go a step further and put C in line with general usage of special characters as they are normalized by Unicode. In particular, it is time to get rid of restrictions in operator naming that stem from the limited availability of special characters 30 years ago, when all of this was invented.
Continue reading “Unicode operators for C”
Some time ago I had advertised for one of my new toys, Modular C, an extension of the C language aiming for modularity, and, more generally for an easier use. Since then it has gained some new features and I have rounded up some edges, so you all should definitively have another look 🙂
Among the new features are
- complete Unicode support (identifiers, operators)
- finite code unrolling (
- programmable expression contexts (e.g for modulo arithmetic or string operations)
Also, there is now some concise documentation, at
You find the latest version of my book at the usual place at
This now contains all the material that I plan to put into it. New are “experience” parts about performance, function-like macros and
_Generic, control flow, threads and atomics. There is in particular a section about memory consistency, probably the most difficult write-up for this book.
These higher level parts have not yet have had the reading they hopefully deserve, so please give it a try. As before, constructive feedback is highly welcome. Thanks to everybody who already did send me comments and corrections!
Constructive comments to this blog are welcome.
This is not the right place for
- feedback about details (missing commas, spelling errors). If you have such details, please collect them and send them to me directly.
- rants against the C standard. This is not the place to let off steam nor to compare to whatever other programming language you prefer. If you have criticism about the C standard, please contribute. The C standards committee is a nice batch of people, don’t be afraid. And if you have concrete proposals, also it would be much better to contact me (or any other member of the committee) directly and see how you may invest yourself in the ISO process.
Also, comments that come from real people are highly preferred.
With this post I will start to discuss a series of modifications of the C standard that I have (or will) propose for C2x. As a starting point there is the observation that the passage from one C standard to the next was not easy in the past. This, neither for implementers of C compilers nor for users, because it was not easy to capture partial improvements. Basically for gcc, e.g., you had to add
-std=c11 or similar, and then test for the version number to see if a particular feature is implemented. This task then was even more complicated because some of the new features are language, and some are library.
This was tedious and error prone, and I think we should avoid such difficulties in the future.
Continue reading “Ease the transition between C standards”
I already have posted about the evilness of cast some time ago, but recently I have seen that there is still much confusion out there about the C rules that pointer casts, also called type punning, break. So I will try to give it a more systematic approach, here.
In fact, I think we should distinguish two different sets of rules, the effective type rules that are explicitly written up in the C standard (6.5 p6 and p7), and the strict aliasing rules that are consequence of these, but that concern only a very special use case of type punning. They represent only one of the multiple ways a violation of the effective type rules can damage the program state.
Continue reading “Effective types and aliasing”
In a document to the standards committee of last year I had observed a set of unfortunate inconsistencies in C11’s specification of arithmetic operations for atomics. As you perhaps know such operations can be specified with operators
a++ (in the language part) or generic functions
atomic_fetch_add(&a, 1) (in the library), but unfortunately the two parts had not been redacted to fit well in all places.
My new document Minimal Suggested Corrigendum for Arithmetic on Atomic Objects will hopefully make it as proposed corrigendum into the next “bugfix” version of the standard, and hopefully this new version will see the light and the end of 2017. It will perhaps not be with the exact words as they are presented, but I think that the text already comes close to what the intent of the committee had been, and to what implementors actually do, anyhow.
Since decades, C is one of the most widely used programming languages, and is used successfully for large software projects that are ubiquitous in modern computing devices of all scales. For many programmers, software projects and commercial enterprises C has advantages (relative simplicity, faithfulness to modern architectures, backward and forward compatibility) that largely outweigh its shortcomings. Among these shortcomings, is a lack of two important closely related features: modularity and reusability. C misses to encapsulate different translation units (TU) properly: all symbols that are part of the interface of a software unit such as functions are shared between all TU that are linked together into an executable.
Continue reading “Modular C”