Linux kernel code uses "statement-expression" and typeof extension that makes it only compilable under gcc.
Linux内核代码使用“语句表达式”和扩展类型，这使得它只能在gcc下编译。
More I think about it, more it doesn't make sense.
我想得越多，就越说不通。
It defeats the purpose of portability and standard C. (now linux kernel code needs a specific compiler that supports gcc extensions).
它破坏了可移植性和标准c的目的(现在linux内核代码需要一个支持gcc扩展的特定编译器)。
Was it a bad design choice or was there a specific reason for making linux kernel code specific to gcc?
这是一个糟糕的设计选择，还是有特定的原因使linux内核代码特定于gcc?
EDIT: When I said it defeats portability, I used it in different context. I was thinking, by conforming to standard C, it would be accepted to ANY compiler that supports standard C (which is exactly the purpose of creating a standard -- to unify all different dialects of C), hence being more portable. Of course, since gcc is so popular, and gcc supports zillion architectures, this line is almost meaningless. I am just asking if there was a specific rationale behind not conforming to standard C.
编辑:当我说它破坏了可移植性时，我在不同的上下文中使用了它。我在想，通过遵循标准C，它将被任何支持标准C的编译器所接受(这正是创建标准的目的——统一所有不同的C方言)，因此更具有可移植性。当然，由于gcc非常流行，并且gcc支持大量的体系结构，这一行几乎没有意义。我只是想问，不符合标准C的背后是否有特定的理由。
4 个解决方案
#1
29
Why would the Linux kernel developers worry about making their code work on say Microsoft Visual Studio compiler or the IBM xlC compilers?
为什么Linux内核开发人员会担心让他们的代码运行在Microsoft Visual Studio编译器或IBM xlC编译器上?
When you're writing a kernel, you need very precise control over a lot more stuff, like exact memory layout, than you do (generally) in userspace. Such controls are not really accounted for in the C standard (left as implementation defined characteristics for instance), so either some extensions are necessary, or you need to rely on the compiler's quirks.
当您编写内核时，您需要非常精确地控制更多的东西，比如精确的内存布局，而不是在userspace中(通常)。这样的控件在C标准中并没有得到真正的解释(例如，左边是实现定义的特性)，所以要么需要一些扩展，要么需要依赖编译器的怪癖。
Sticking with one specific compiler, taking advantage of its extensions, is a rational decision. The code doesn't need to be portable across compilers - it needs to be efficient and portable across different hardware platforms.
坚持使用一个特定的编译器，利用它的扩展，这是一个理性的决定。代码不需要在编译器之间移植——它需要在不同的硬件平台上高效和可移植。
#2
13
Here's some good background on the specific extensions used. It's not really written from the perspective of "why?", but it should give you some good background on the reasons for choosing this approach:
这里有一些关于所使用的特定扩展的良好背景。它不是从“为什么”的角度来写的，但它应能让你了解选择这种方法的原因:
http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
#3
5
The Linux Kernel code is a complicated piece of software. The more facilities gcc provides them with, they happier the coders would be.
Linux内核代码是一个复杂的软件。gcc提供给他们的设施越多，编码人员就越高兴。
Why would they care about portability? gcc compiles code under virtually every hardware configuration PLUS it provides them with good features. Why would they care if Linux could or could not be compiled with another compiler?
他们为什么要关心便携性呢?gcc在几乎所有硬件配置下编译代码，并且它提供了良好的特性。为什么他们会关心Linux能不能用另一个编译器编译?
Today, portable code is such a common concept for us that we believe it should be existent everywhere. But that is not the case. For example, if a compiler provides real-time extensions to C, NASA would use it without care for portability. The important point being the features are too good to sacrifice for a portability that is never used (I mean, who would compile the kernel with MS Visual Studio for example?)
今天，可移植代码对我们来说是一个非常普遍的概念，我们认为它应该存在于任何地方。但事实并非如此。例如，如果编译器为C提供实时扩展，NASA就会不考虑它的可移植性。重要的一点是，这些特性太好了，不能牺牲它的可移植性(我的意思是，谁会用MS Visual Studio编译内核呢?)
#4
3
Once the kernel is compiled, it doesn't leave "traces" of its compilation environment around to taint the running kernel experience.
一旦内核被编译，它就不会在周围留下编译环境的“痕迹”来破坏运行中的内核体验。
I'd say it's just a matter of expedience. The kernel also contains bits of assembly, and assembly isn't exactly portable either. Perhaps if the "mission" of the kernel was to write a kernel which could be compiled on multiple C compilers, the complaint would fall on more attentive ears.
我认为这只是权宜之计。内核也包含一些程序集，而且程序集也不是完全可移植的。也许，如果内核的“任务”是编写一个可以在多个C编译器上编译的内核，那么这些抱怨就会被更细心的人听到。
#1
29
Why would the Linux kernel developers worry about making their code work on say Microsoft Visual Studio compiler or the IBM xlC compilers?
为什么Linux内核开发人员会担心让他们的代码运行在Microsoft Visual Studio编译器或IBM xlC编译器上?
When you're writing a kernel, you need very precise control over a lot more stuff, like exact memory layout, than you do (generally) in userspace. Such controls are not really accounted for in the C standard (left as implementation defined characteristics for instance), so either some extensions are necessary, or you need to rely on the compiler's quirks.
当您编写内核时，您需要非常精确地控制更多的东西，比如精确的内存布局，而不是在userspace中(通常)。这样的控件在C标准中并没有得到真正的解释(例如，左边是实现定义的特性)，所以要么需要一些扩展，要么需要依赖编译器的怪癖。
Sticking with one specific compiler, taking advantage of its extensions, is a rational decision. The code doesn't need to be portable across compilers - it needs to be efficient and portable across different hardware platforms.
坚持使用一个特定的编译器，利用它的扩展，这是一个理性的决定。代码不需要在编译器之间移植——它需要在不同的硬件平台上高效和可移植。
#2
13
Here's some good background on the specific extensions used. It's not really written from the perspective of "why?", but it should give you some good background on the reasons for choosing this approach:
这里有一些关于所使用的特定扩展的良好背景。它不是从“为什么”的角度来写的，但它应能让你了解选择这种方法的原因:
http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
#3
5
The Linux Kernel code is a complicated piece of software. The more facilities gcc provides them with, they happier the coders would be.
Linux内核代码是一个复杂的软件。gcc提供给他们的设施越多，编码人员就越高兴。
Why would they care about portability? gcc compiles code under virtually every hardware configuration PLUS it provides them with good features. Why would they care if Linux could or could not be compiled with another compiler?
他们为什么要关心便携性呢?gcc在几乎所有硬件配置下编译代码，并且它提供了良好的特性。为什么他们会关心Linux能不能用另一个编译器编译?
Today, portable code is such a common concept for us that we believe it should be existent everywhere. But that is not the case. For example, if a compiler provides real-time extensions to C, NASA would use it without care for portability. The important point being the features are too good to sacrifice for a portability that is never used (I mean, who would compile the kernel with MS Visual Studio for example?)
今天，可移植代码对我们来说是一个非常普遍的概念，我们认为它应该存在于任何地方。但事实并非如此。例如，如果编译器为C提供实时扩展，NASA就会不考虑它的可移植性。重要的一点是，这些特性太好了，不能牺牲它的可移植性(我的意思是，谁会用MS Visual Studio编译内核呢?)
#4
3
Once the kernel is compiled, it doesn't leave "traces" of its compilation environment around to taint the running kernel experience.
一旦内核被编译，它就不会在周围留下编译环境的“痕迹”来破坏运行中的内核体验。
I'd say it's just a matter of expedience. The kernel also contains bits of assembly, and assembly isn't exactly portable either. Perhaps if the "mission" of the kernel was to write a kernel which could be compiled on multiple C compilers, the complaint would fall on more attentive ears.
我认为这只是权宜之计。内核也包含一些程序集，而且程序集也不是完全可移植的。也许，如果内核的“任务”是编写一个可以在多个C编译器上编译的内核，那么这些抱怨就会被更细心的人听到。