linux内核对编译器要求,为什么linux内核使用非标准C(gcc特定功能)编码？

Linux内核代码使用"statement-expression"和typeof扩展，使其只能在gcc下编译。

我想的更多，更没有意义。

它违背了便携性和标准C的目的。

(现在linux内核代码需要一个支持gcc扩展的特定编译器)。

这是一个糟糕的设计选择还是有特定的理由让linux内核代码特定于gcc？

编辑：当我说它破坏了可移植性时，我在不同的环境中使用它。 我在思考，通过符合标准C，它将被任何支持标准C的编译器所接受(这正是创建标准的目的 - 统一C的所有不同方言)，因此更加便携。 当然，由于gcc如此受欢迎，并且gcc支持zillion架构，因此这条线几乎毫无意义。 我只是问是否有一个特定的理由背后不符合标准C.

使用GNU编译器编写GNU Linux的原因为何奇怪？谁说Linux的设计是为了移植到其他编译器？

Linux不是代码质量或可移植性。这是关于世界统治的。

这听起来并不像SO的话题。我不太了解程序员的范围，无论是否应该移动到那里。

@Oli Charlesworth clang能够编译一个可用的Linux内核，而clang不是GNU编译器，但我同意。 :)

那么，linux是用GNU编译器编写的，因为它只是想让人们使用GNU编译器？我只是想知道是否存在任何其他性能问题而不是政治或社会问题。我只是认为如果它坚持标准C(如果没有性能问题)，它会使一切变得更加有效。

Intel C编译器还编译Linux内核。

@WTP我以为clang是关于无可比拟的标准一致性？

@Seth Carnegie可能是，但它有一些(如果不是全部)GCC扩展。但是你可以禁用它们。

@OliCharlesworth Linux内核不是GNU / Linux，GNU / Linux指定分发中包含的核心实用程序是GNU实现。应该可以将Linux内核与核心实用程序的另一个实现一起使用，例如BSD，那不是GNU / Linux。

@cnicutar不是因为intel c编译器必须加倍努力来实现gcc扩展吗？

@SHH一旦发生这种情况，它们就不再是"gcc扩展"。它们是"某些人需要的东西，由一些编译器实现"。许多以前的gcc扩展现在是标准的C99功能。

@Kevin：这是一个公平的观点。

@SHH：小心解释如何使用运行的编译器并为多种架构生成代码(大约)"破坏可移植性"？

@ninjalj当我说失败便携性时，我在不同的背景下使用它。我认为，通过符合标准C，它将被任何支持标准C的编译器所接受(这正是创建标准的目的 - 统一C的所有不同方言)，因此更具可移植性。当然，由于gcc如此受欢迎并且gcc支持zillion架构，因此这种情况几乎毫无意义。我只是问有没有符合标准C的具体理由。

为什么Linux内核开发人员担心让他们的代码在Microsoft Visual Studio编译器或IBM xlC编译器上运行？

当你编写内核时，你需要非常精确地控制更多的东西，比如精确的内存布局，而不是你(通常)在用户空间中。这样的控件在C标准中并没有真正考虑到(例如，左边是实现定义的特性)，因此需要一些扩展，或者你需要依赖编译器的怪癖。

坚持使用一个特定的编译器，利用它的扩展，是一个理性的决定。代码不需要跨编译器可移植 - 它需要在不同的硬件平台上高效且可移植。

我不知道gcc扩展功能允许您精确控制更多内容，如内存布局或最大化效率。这不是建筑专用语言的工作吗？我的意思是，如果内核开发人员想要最高效率，他们为什么不使用汇编语言呢？看起来内核中使用的任何gcc扩展都可以被标准C替换(如果我错了，请纠正我)。

编写程序集比编写C语言更费时，更困难。即使在内核中，它也局限于以下几个方面：a)它根本无法用C语言表达，或b)对于非常具体，性能关键的代码片段而言C编译器没有"完美"。使用的一些扩展可能会被标准C替换，但重点是什么？如果用exts写起来更容易，为什么要这么麻烦？还记得C标准的发展。随着时间的推移，许多编译器会实现一些扩展，因为它们很有用。然后，最终，他们可以成为标准

最后，这非常重要：Linux内核完全不关心普通应用程序的可移植性。他们编写他们运行的环境并提供给用户空间。内核关心的可移植性与"普通"应用程序的可移植性完全不同。

@Mat：Linux内核确实关心可移植性，这就是为什么它使用已经移植的编译器并为多个架构生成代码的原因。

限制为gcc可能是一个功能而不是一个bug，如果他们支持其他编译器，人们将尝试在这些编译器下编译内核，这将指数级地增加内核可以编译的不同配置的数量，以及其他使用太空计划。支持噩梦可能不值得。

@ssh，最简单的例子是没有标准等价物的__attribute__。

@SHH：如果C的扩展版本允许一个源代码在许多不同的体系结构上执行任务，否则每个体系结构需要单独的汇编语言代码，为什么程序员必须使用汇编？我观察到一些人似乎反过来反对将C用于此类目的，但我认为这种反对没有充分的理由。

以下是使用的特定扩展的一些很好的背景知识。它不是从"为什么？"的角度写的，但是它应该给你一些关于选择这种方法的原因的好背景：

哇，谢谢这篇精彩的文章。

Linux内核代码是一个复杂的软件。 gcc为他们提供的设施越多，编码员就会越快乐。

他们为什么要关心便携性呢？ gcc几乎在每个硬件配置下编译代码PLUS为它们提供了良好的功能。他们为什么要关心Linux是否可以用其他编译器编译？

今天，便携式代码对我们来说是一个普遍的概念，我们相信它应该存在于任何地方。但事实并非如此。例如，如果编译器提供C的实时扩展，NASA将使用它而不用担心可移植性。重要的一点是功能太好了，不能牺牲从未使用的可移植性(我的意思是，谁会用MS Visual Studio编译内核？)

并非gcc支持的每个硬件都具有gcc的优良功能。

你什么意思？我想到的功能是OP所要求的类型"statement-expression" and typeof。

我的意思是gcc没有为每个支持的平台提供良好的性能。

一旦内核被编译，它就不会留下其编译环境的"痕迹"来污染正在运行的内核体验。

我说这只是一个权宜之计。内核还包含一些程序集，而程序集也不是完全可移植的。也许如果内核的"使命"是编写一个可以在多个C编译器上编译的内核，投诉将落在更加专心的耳朵上。