Linux Kernel Moving Ahead With Going From C89 To C11 Code

[Dar13]

So only C17 is newer than C11, right?

C2x (looking like it'll be C23), is currently in the process of being finalized, but C17 is indeed the newest official C standard.

[coder]

Do the kernel dev's actually go through and install that version (5.1) of GCC and use as their daily driver? As an example on openSUSE, the base compiler is 7.5 so they would have to seriously go out of their way to install such an old compiler.

You can do your builds in a chroot or a container, I suppose. In either case, the tools you'd be using for building are independent of what the host system has installed. Indeed, this is how most distros build their packages, so that you get deterministic build products, regardless of what's installed on the host system.

However, GCC 5.1 is just a minimum requirement. So, most developers are probably using much newer tools and only some CI/regression test needs to actually check that the kernel is still buildable with 5.1 and that such builds work correctly.

[coder]

Good news! However, it's going to make back-porting of patches annoying, but it's a pill that eventually has to be swallowed for the kernel to keep moving forward.

I wish C would adopt templates. Even as I say that, it seems as if C++ is trying to move away from them, as much as possible. I guess C11 tried to split the difference, with the _Generic keyword.

[dekernel]

You can do your builds in a chroot or a container, I suppose. In either case, the tools you'd be using for building are independent of what the host system has installed. Indeed, this is how most distros build their packages, so that you get deterministic build products, regardless of what's installed on the host system.

However, GCC 5.1 is just a minimum requirement. So, most developers are probably using much newer tools and only some CI/regression test needs to actually check that the kernel is still buildable with 5.1 and that such builds work correctly.

Thanks for the info. I just wasn't sure how the "typical" kernel dev worked these items out.

[coder]

I'd also hazard a guess that even with C11 one can pass a flag or switch to tell the C11 compiler to force-use the C89 standard?

You can only compile against one version of the language standard. So, you're either using C89 or you're using C11. As the code starts to get patches employing C11 features, they will break the build in C89 mode.

To move forward, you have to accept making it costly (or virtually impossible) to go back. A lot of progress is like that. That's why they took so long to make this move. The harder it is to go back, the more slowly and cautiously you move forward.

To that end, I'm surprised to see them skip C99. Then again, that move was overdue and I can see the logic in just going straight to C11. Also, C11 makes certain parts of C99 optional (see below), but I have no idea if that factored into their decision.

Someone enlighted us on what's better in C11 than C89 besides just the improved commenting format.

From Wikipedia...

C99 introduced several new features, many of which had already been implemented as extensions in several compilers:

• inline functions
• intermingled declarations and code: variable declaration is no longer restricted to file scope or the start of a compound statement (block), facilitating static single assignment form
• several new data types, including long long int, optional extended integer types, an explicit boolean data type, and a complex type to represent complex numbers
• variable-length arrays (although subsequently relegated in C11 to a conditional feature that implementations are not required to support)
• flexible array members
• support for one-line comments beginning with //, as in BCPL, C++ and Java
• new library functions, such as snprintf
• new headers, such as <stdbool.h>, <complex.h>, <tgmath.h>, and <inttypes.h>
• type-generic math (macro) functions, in <tgmath.h>, which select a math library function based upon float, double, or long double arguments, etc.
• improved support for IEEE floating point
• designated initializers (for example, initializing a structure by field names: struct point p = { .x = 1, .y = 2 } )
• compound literals (for instance, it is possible to construct structures in function calls: function((struct x) {1, 2}))
• support for variadic macros (macros with a variable number of arguments)
• restrict qualification allows more aggressive code optimization, removing compile-time array access advantages previously held by FORTRAN over ANSI C
• universal character names, which allows user variables to contain other characters than the standard character set
• keyword static in array indices in parameter declarations

C11 includes several changes to the C99 language and library specifications, such as:

• Alignment specification (_Alignas specifier, _Alignof operator, aligned_alloc function, <stdalign.h> header)
• The _Noreturn function specifier and the <stdnoreturn.h> header
• Type-generic expressions using the _Generic keyword. For example, the following macro cbrt(x) translates to cbrtl(x), cbrt(x) or cbrtf(x) depending on the type of x:

#define cbrt(x) _Generic((x), \
long double: cbrtl, \
default: cbrt, \
float: cbrtf)(x)

• Multi-threading support (_Thread_local storage-class specifier, <threads.h> header including thread creation/management functions, mutex, condition variable and thread-specific storage functionality, as well as <stdatomic.h> for atomic operations supporting the C11 memory model).
• Improved Unicode support based on the C Unicode Technical Report ISO/IEC TR 19769:2004 (char16_t and char32_t types for storing UTF-16/UTF-32 encoded data, including conversion functions in <uchar.h> and the corresponding u and U string literal prefixes, as well as the u8 prefix for UTF-8 encoded literals).
• Removal of the gets function (in favor of safer fgets), which was deprecated in the previous C language standard revision, ISO/IEC 9899:1999/Cor.3:2007(E).
• Bounds-checking interfaces (Annex K).
• Analyzability features (Annex L).
• More macros for querying the characteristics of floating-point types, concerning subnormal floating-point numbers and the number of decimal digits the type is able to store.
• Anonymous structures and unions, useful when unions and structures are nested, e.g. in struct T { int tag; union { float x; int n; }; };.
• Static assertions, which are evaluated during translation at a later phase than #if and #error, when types are understood by the translator.
• An exclusive create-and-open mode ("…x" suffix) for fopen. This behaves like O_CREAT|O_EXCL in POSIX, which is commonly used for lock files.
• The quick_exit function as a third way to terminate a program, intended to do at least minimal deinitialization if termination with exit fails.
• A new timespec_get function and corresponding structure in <time.h> with a degree of POSIX compatibility.
• Macros for the construction of complex values (partly because real + imaginary*I might not yield the expected value if imaginary is infinite or NaN).

Mandatory parts of C99 that C11 makes optional are:

• Complex types (<complex.h>)
• Variable length arrays

Optional parts of C11 that were already optional in C99:

• IEC 60559 floating-point arithmetic (Annex F)
• IEC 60559 compatible complex arithmetic (Annex G)

Optional features new to C11:

• Analyzability (Annex L)
• Bounds-checking interfaces (Annex K) - Wikipedia notes this is controversial, not widely-implemented, and likely to be removed.
• Multithreading (<threads.h>)
• Atomic primitives and types (<stdatomic.h> and the _Atomic type qualifier)

Again, credit (and blame) goes to the relevant Wikipedia pages.

[coder]

BTW, I think many of these features that are actually relevant to kernel development are things they already got from -std=gnu89 (as opposed to -std=c89). It's worth noting that the threading & floating-point stuff aren't used in the kernel, so not relevant. Nor is any of the standard library stuff.

For instance, gnu89 includes things like inline functions, variadic macros, intermingled declarations and code, end-of-line comments, etc. The full list of extensions in GCC 5 is here:

https://gcc.gnu.org/onlinedocs/gcc-5...xtensions.html

Not being a kernel developer, I can't say which of these are allowed in the kernel. However, for the curious, its coding style guide is here:

https://www.kernel.org/doc/html/late...ing-style.html

[betty567]

Considering how annoyed Linus is because of the bad shape the C standard is in, maybe we'll see an at least partial R...-based rewrite sooner than expected? At least I expect some changes in the near future.

Or maybe the people who like Rust so much can start writing new things from scratch in their favorite language, instead of trolling the entire internet demanding that people re-write existing code in an unproven language, as if that should be every project's top priority for the next several years it would take.

I'm all for C11 in the kernel if it actually works. But last time I attempted to upgrade a C89 project to C11, not that long ago, compiler and libc support for C11 were still garbage. Of course, the kernel doesn't depend on libc, but I got the impression that C11 is still not well supported.

[sinepgib]

Or maybe the people who like Rust so much can start writing new things from scratch in their favorite language, instead of trolling the entire internet demanding that people re-write existing code in an unproven language, as if that should be every project's top priority for the next several years it would take.

I'm all for C11 in the kernel if it actually works. But last time I attempted to upgrade a C89 project to C11, not that long ago, compiler and libc support for C11 were still garbage. Of course, the kernel doesn't depend on libc, but I got the impression that C11 is still not well supported.

I don't know which toolchain you used, but GCC and clang pretty much always have full support on day 1. It's MSVC that didn't even support C99 in 2011 at least (when I learned programming), and if I have to guess doesn't even support it today. But that speaks of MS support for C, rather than the common picture.

[darkonix]

Considering how annoyed Linus is because of the bad shape the C standard is in, maybe we'll see an at least partial R...-based rewrite sooner than expected? At least I expect some changes in the near future.

Not realisticly. Any partial rewrite in another language would be an effort several orders of magnitude than supporting C11. It is not even comparable.

Linux already is interested in the experimental support for new Rust modules/drivers project. A rewrite is not going to happen before that project matures and shows useful results. Not in short-medium term for sure.

[jacob]

Considering how annoyed Linus is because of the bad shape the C standard is in, maybe we'll see an at least partial R...-based rewrite sooner than expected? At least I expect some changes in the near future.

AFAIK no rewrite in R... is currently planned. R... will be used for new developments and, at least for the foreseeable future, for self-contained leaf subsystems and drivers only.