|Linux To Move To C11|
|Written by Harry Fairhead|
|Wednesday, 02 March 2022|
- as long as there are no problems. Linus Torvalds has long expressed a preference for the original C and his dislike of, or despair at, C++. Could he be mellowing?
Probably not, as moving to C11 isn't such a huge step. If you select the right compiler switches then you can write C11 as if it was C89, the current old version of C used in Linux and preferred by Linus up to now.
A bigger step forward is allowing Rust into the Kernel. This is an ongoing story, but essentially we have the first steps to allowing drivers and other modules to be written in Rust. Why such an adventurous acceptance of a really innovative language and so much conservatism when it comes to good old C? The answer is that Rust is a bit of a promising unknown. It seems it is worth a try, but later dialects of C and particularly C++ are known to have big problems and so it is much easier to reject them.
C suffers from the problem of undefined behavior and its potential for agressive optimisation. The problem is that if something is defined to be undefined then the compiler writers can implement whatever they like and call it optimization. For example, if you place a null for loop in a program to introduce a slight time delay then this can be optimized away without any comment. To keep the null loop you have to make sure to set the right level of optimization or mark a variable in the loop as volatile. This isn't an example of undefined behavior, but it is similar. Linus has never been pleased with the lengths that compiler writers seem to be prepared to go to win optimization competitions:
"Lookie here, your compiler does some absolutely insane things with the spilling, including spilling a *constant*. For chrissake, that compiler shouldn't have been allowed to graduate from kindergarten. We're talking "sloth that was dropped on the head as a baby" level retardation levels here..."
The same sort of distrust applies to newer standards of C. The problem seems to be caused by the standards and the compiler writers forgetting that, despite what many seem to believe, C is a high-level assembler and it should stay in touch with the hardware. Some have claimed that the whole standardisation of C has made it unsable for OS developement:
"... through the course of the ISO Standards process, added many attributes of more conventional programming languages and become less suitable for operating systems development. Operating system programming continues to be done in non-ISO dialects of C."
C99 in particular caused problems because it insisted on some of its modifications to the language and this made it less than backward compatible with C89. It had so many problems that C11 is considered to be a "bug fix" that put things right. This is the reason why Linus has decided that a jump to C11 is better than going through C99. Of course, there is C17 to consider and perhaps soon C2x will get a value for x.
Interestingly the move has been motivated by a potential bug caused by the lack of being able to declare a variable within the scope of a for loop. This is something that C99 introduced:
"The whole reason this kind of non-speculative bug can happen is that we historically didn't have C99-style "declare variables in loops". So list_for_each_entry() - and all the other ones - fundamentally always leaks the last HEAD entry out of the loop, simply because we couldn't declare the iterator variable in the loop itself." Linus Torvalds
So to allow variables to be declared within loops, Linux is moving to not C99 but C11.
"But we still don't do "gnu99", because we had some odd problem with some ancient gcc versions that broke documented initializers." Linus Torvalds
So we might see C11 in Linux 5.18 as long as nothing unexpected crops up.
Personally I'd like to see an ISO C standard that acknowledges that C is used with real machines and that in no cases is there ever such a thing as undefined behaviour - only system-dependent behavior.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Wednesday, 02 March 2022 )|