Matthew Wilcox 最近意识到，依赖 Plan 9 变种 C 编程语言提供的 C 扩展可能具有价值。这只需要在编译内核时使用 -fplan9-extensions 命令行参数。正如 Matthew 指出的，GCC 从 4.6 版本开始就支持 Plan 9 扩展，而这正是内核支持的最低版本。因此，理论上不会有冲突。

Nick Desaulniers 认为，向任何项目添加 -f 编译器标志始终需要仔细考虑。根据扩展的用途，它们可能是有帮助的，也可能是非常危险的。

在当前情况下，Matthew 希望使用 Plan 9 扩展来节省循环内存分配中的宝贵字节，该分配需要存储对“下一个”值的引用。Matthew 说，使用这些扩展，他可以嵌入“下一个”值，而不会破坏各种现有的函数调用。

Nick 还建议使任何此类扩展依赖成为可选的，以便其他编译器能够继续编译内核。

看起来似乎会就正确的处理方式进行一些来回讨论，但 Linus Torvalds 立即介入否决了整个概念，并说

请不要这样做。

被称为“ms”扩展的 plan9 扩展子集是可以接受的。这是一个合理的做法，并且是我们已经拥有的未命名结构的非常自然的扩展——即能够预先声明该未命名的结构/联合。

但是完整的 plan9 扩展很糟糕，并且使得编写“方便”的代码变得太容易，但由于类型被静默转换，作为局外人很难阅读。

而且我认为你想要的就是显式的静默转换。

所以，不要这样做。使用宏或内联函数来显式地进行转换，以便在 grepping 时显示出来。

“一个额外的参数”对于一些根本不常见的事情来说不是一个有力的论据。像这样的非标准特性的优点需要非常有说服力。

自从第一天起，我们就使用了各种 gcc 扩展（“inline”可能是最大的一个，它花了 _永远_ 才成为标准 C），但是这些东西需要有非常充分的理由。

可以被宏或辅助内联隐藏的“一个额外的参数”根本不是一个有力的论据。

Nick 对此观点表示理解，并说

隐式转换是 JavaScript 等语言中最常被指出的“缺陷”。我理解它们为什么方便，但由此产生的令人惊讶的错误并不能抵消它们的成本（再次声明，这只是我的观点），而且开发人员经常无法理清这些隐式转换规则（无论我们谈论的是 JavaScript 还是 C）。

在 Linus 的谴责之后，没有进行真正的对话。但是，使用哪些编译器扩展以及不使用哪些编译器扩展的问题非常有趣，特别是对于像 Linux 这样无处不在并且运行一切的项目。考虑到它需要支持的所有不同环境，这种支持需要包括支持各种开发平台的可能性。在某种程度上，Linus 的论点，即 Matthew 试图创建难以阅读的代码是相关的，但其他编译器和其他构建环境也需要能够支持 Linux 开发，这也是相关的。

注意：如果您在上面被提及并希望在评论区上方发布回复，请将包含您的回复文本的消息发送至 ljeditor@linuxjournal.com。