为什么linux内核使用非标准的C编写(gcc特有的特性)？
Linux内核代码使用“语句表达式”和typeof扩展，这使得它只能在gcc下编译。
我想得越多，它就越没有意义。
它违背了可移植性和标准C的目的(现在linux内核代码需要一个支持gcc扩展的特定编译器)。
这是一个糟糕的设计选择，还是有特定的原因让linux内核代码专用于gcc？
编辑:当我说它破坏了可移植性时，我在不同的上下文中使用了它。我在想，通过遵循标准C，它将被任何支持标准C的编译器所接受(这正是创建标准的目的--统一C的所有不同方言)，因此更具可移植性。当然，由于gcc如此受欢迎，而gcc又支持千千万万的架构，所以这条线几乎没有意义。我只是问不符合标准C的背后是否有特定的理由。
回答 4
Stack Overflow用户
发布于 2011-11-16 05:43:12
为什么Linux内核开发人员会担心他们的代码在Microsoft Visual Studio编译器或IBM xlC编译器上工作？
当您编写内核时，您需要非常精确地控制比在用户空间中(通常)要多得多的东西，比如确切的内存布局。这样的控制在C标准中并没有真正考虑到(例如，作为实现定义的特征)，所以要么需要一些扩展，要么你需要依赖于编译器的怪癖。
坚持使用一个特定的编译器，利用它的扩展，是一个理性的决定。代码不需要跨编译器移植-它需要在不同的硬件平台上高效和可移植。
Stack Overflow用户
发布于 2011-11-16 05:59:30
这里有一些关于使用的特定扩展的很好的背景知识。这篇文章并不是从“为什么？”的角度写的，但它应该会给你一些关于选择这种方法的原因的良好背景：
Stack Overflow用户
发布于 2011-11-16 05:40:52
Linux内核代码是一个复杂的软件。gcc为他们提供的设施越多，他们就会越高兴。
他们为什么要关心可移植性呢？实际上，gcc在每种硬件配置下都会编译代码，并为它们提供了良好的功能。为什么他们会关心Linux能不能用其他编译器编译？
今天，可移植代码对我们来说是一个如此常见的概念，以至于我们相信它应该无处不在。但事实并非如此。例如，如果编译器为C语言提供了实时扩展，NASA就会使用它，而不关心可移植性。重要的一点是，这些特性太好了，不能为了一个从未使用过的可移植性而牺牲(我的意思是，谁会用MS Visual Studio编译内核呢？)
https://stackoverflow.com/questions/8143417
复制相似问题