它违背了可移植性和标准 C 的目的。
（现在linux内核代码需要一个支持gcc扩展的特定编译器）。
这是一个糟糕的设计选择，还是有特定原因让 Linux 内核代码特定于 gcc？
编辑：当我说它破坏了可移植性时，我在不同的上下文中使用了它。我在想，通过遵守标准 C，它会被任何支持标准 C 的编译器所接受（这正是创建标准的目的——统一 C 的所有不同方言），因此更加可移植。当然，由于 gcc 如此流行，并且 gcc 支持无数种体系结构，因此这一行几乎没有任何意义。我只是想问不符合标准 C 是否有具体的理由。
为什么 Linux 内核开发人员会担心他们的代码能否在 Microsoft Visual Studio 编译器或 IBM xlC 编译器上运行？
当您编写内核时，您需要非常精确地控制比用户空间中（通常）更多的东西，例如精确的内存布局。 C 标准中并未真正考虑此类控件（例如，保留为实现定义的特征），因此要么需要一些扩展，要么需要依赖编译器的怪癖。
