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.