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”
Recently it showed that the C standard seems to be ambiguous on how to interpret the controlling expression of
_Generic, the one that determines the choice. Compiler implementors have given different answers to this question; we will see below that there is code that is interpreted quite differently by different existing compilers. None of them is “wrong” at a first view, so this tells us that we must be careful when we use
_Generic. In this post I will try to explain the problem and to give you some work around for common cases.
Continue reading “The controlling expression of _Generic”