Linux内核代码使用“statement-expression”和typeof扩展，使其只能在gcc下编译 .
我想的更多，更没有意义 .
它违背了可移植性和标准C的目的 . （现在linux内核代码需要一个支持gcc扩展的特定编译器） .
这是一个糟糕的设计选择还是有特定的理由让linux内核代码特定于gcc？
编辑：当我说它破坏了可移植性时，我在不同的环境中使用它 . 我在思考，通过符合标准C，它将被任何支持标准C的编译器所接受（这正是创建标准的目的 - 统一C的所有不同方言），因此更加便携 . 当然，由于gcc如此受欢迎，并且gcc支持zillion架构，因此这条线几乎毫无意义 . 我只是问是否有一个特定的理由背后不符合标准C.
4 回答
为什么Linux内核开发人员担心让他们的代码在Microsoft Visual Studio编译器或IBM xlC编译器上运行？
当你编写内核时，你需要非常精确地控制更多的东西，比如精确的内存布局，而不是你（通常）在用户空间中 . 这样的控件在C标准中并没有真正考虑到（例如，左边是实现定义的特性），因此需要一些扩展，或者你需要依赖编译器的怪癖 .
坚持使用一个特定的编译器，利用它的扩展，是一个理性的决定 . 代码不需要跨编译器可移植 - 它需要在不同的硬件平台上高效且可移植 .
以下是使用的特定扩展的一些很好的背景知识 . 它不是从“为什么？”的角度写的，但是它应该给你一些关于选择这种方法的原因的好背景：
http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
Linux内核代码是一个复杂的软件 . gcc为他们提供的设施越多，编码员就会越快乐 .
他们为什么要关心便携性呢？ gcc几乎在每个硬件配置下编译代码PLUS为它们提供了良好的功能 . 他们为什么要关心Linux是否可以用其他编译器编译？
今天，便携式代码对我们来说是一个普遍的概念，我们相信它应该存在于任何地方 . 但事实并非如此 . 例如，如果编译器提供C的实时扩展，NASA将使用它而不用担心可移植性 . 重要的一点是功能太好了，不能牺牲从未使用的可移植性（我的意思是，谁会用MS Visual Studio编译内核？）
一旦内核被编译，它就不会留下其编译环境的“痕迹”来污染正在运行的内核体验 .
我说这只是一个权宜之计 . 内核还包含一些程序集，而程序集也不是完全可移植的 . 也许如果内核的“使命”是编写一个可以在多个C编译器上编译的内核，投诉将落在更加专心的耳朵上 .