Matthew Wilcox recently realized there might be a value in depending on C extensions provided by the Plan 9 variant of the C programming language. All it would require is using the -fplan9-extensions command-line argument when compiling the kernel. As Matthew pointed out, Plan 9 extensions have been supported in GCC as of version 4.6, which is the minimum version supported by the kernel. So theoretically, there would be no conflict.

Nick Desaulniers felt that any addition of -f compiler flags to any project always would need careful consideration. Depending on what the extensions are needed for, they could be either helpful or downright dangerous.

In the current case, Matthew wanted to use the Plan 9 extensions to shave precious bytes off of a cyclic memory allocation that needed to store a reference to the "next" value. Using the extensions, Matthew said, he could embed the "next" value without breaking various existing function calls.

Nick also suggested making any such extension dependencies optional, so that other compilers would continue to be able to compile the kernel.

It looked as though there would be some back and forth on the right way to proceed, but Linus Torvalds immediately jumped in to veto the entire concept, saying:

Please don't.

The subset of the plan9 extensions that are called just "ms" extensions is fine. That's a reasonable thing, and is a very natural expansion of the unnamed structures we already have—namely being able to pre-declare that unnamed structure/union.

But the full plan9 extensions are nasty, and makes it much too easy to write "convenient" code that is really hard to read as an outsider because of how the types are silently converted.

And I think what you want is explicitly that silent conversion.

So no. Don't do it. Use a macro or an inline function that makes the conversion explicit so that it's shown when grepping.

The "one extra argument" is not a strong argument for something that simply isn't that common. The upsides of a nonstandard feature like that needs to be pretty compelling.

We've used various gcc extensions since day #1 ("inline" being perhaps the biggest one that took _forever_ to become standard C), but these things need to have very strong arguments.

"One extra argument" that could be hidden by a macro or a helper inline is simply not a strong argument.

Nick was sympathetic to this point, and said:

Implicit conversions are the most pointed to "defect" in languages like JavaScript. I understand why they're convenient, but the resulting surprising bugs don't outweigh their cost (again, my opinion), and developers frequently can't keep these implicit conversion rules straight (whether we're talking about JavaScript or C).

There was no real conversation after Linus' denunciation. But, the question of which compiler extensions to use and which not to use is very interesting, especially for a project like Linux that's used everywhere and runs everything. With all the different environments it needs to support, that support needs to include the possibility of all sorts of development platforms. To some extent, Linus' argument that Matthew was trying to create hard-to-read code is relevant, but it's also relevant that other compilers and other build environments also need to be able to support Linux development.

Note: if you're mentioned above and want to post a response above the comment section, send a message with your response text to ljeditor@linuxjournal.com.