摘要：近日，Linux 内核社区正酝酿一场引人关注的改动：在即将发布的 Linux 6.19 版本中，内核构建系统可能会默认启用 -fms‑extensions 参数，也就是允许使用 Microsoft C 扩展。

近日，Linux 内核社区正酝酿一场引人关注的改动：在即将发布的 Linux 6.19 版本中，内核构建系统可能会默认启用 -fms‑extensions 参数，也就是允许使用 Microsoft C 扩展。

内核开发者认为，这次改动可能让代码写起来更顺手、更美观，同时也能提升跨平台兼容性。据外媒 Phoronix 报道，Linux 之父 Linus Torvalds 对此变动暂时没有发表反对意见。

从技术上来说，这次变动的核心是让内核构建系统统一开启 -fms-extensions 编译选项。

-fms-extensions 是 GCC 和 Clang 都支持的选项，用来启用微软 Visual C/C++ 编译器的一些非标准语法。其中之一，就是允许在结构体（struct）或联合体（union）中匿名嵌套其他类型。对内核开发者来说，这意味着代码可以写得更简洁、更优雅——在某些场景下甚至还能节省一点栈空间。

过去多年，社区曾多次有人提议默认启用 -fms-extensions，但由于坚持标准 C、担心可移植性问题以及核心开发者意见不一，这些补丁一直没有被采纳。

目前，启用这一特性的两个补丁已经合入 kbuild-next 分支——这是负责内核构建系统的子系统。这意味着社区态度更务实——如果核心开发者和 Linus Torvalds 不反对，这项改动很可能会在 Linux 6.19 合并窗口正式启用。

在提交相关补丁时，开发者 Rasmus Villemoes 在主题为「Kbuild: enable -fms-extensions」的邮件列表中写道：

“有时启用 -fms-extensions 能让代码看起来更美观。但每次有人提议启用 -fms-extensions 时，总有人会说‘不用它也能写代码，而且也不算太糟’，不足以为了这一点新增一个编译标志。

每个用例单独看确实如此，但这也是一种‘鸡生蛋蛋生鸡’的局面。

但正如 Linus 所说，如果我们咬咬牙一次性启用它，那么以后需要用时就能直接用，不必每次都单独为例子辩解。

在 lore.kernel.org 上可以查到这些历史讨论示例：

显然，代码中还有更多地方可以使用它，只是过去的讨论中从未提到过 -fms-extensions。”

另一个补丁为“kbuild: Add ‘-fms-extensions’ to areas with dedicated CFLAGS”，用来确保在特定架构使用自定义 CFLAGS 而非通用的 KBUILD_CFLAGS 时，也能正确传递该选项。

那么对于这些补丁，Linus Torvalds 是什么态度？

从他最近在邮件列表上的发言来看，Linus Torvalds 并不反对在 Linux 6.19 中引入 Microsoft C 扩展。

其实在启用 -fms-extensions 后，内核开发者能在结构体中使用匿名嵌套类型，而无需显式字段名，也可以使得多个子系统的代码可更简洁、更紧凑。另外还能让 GCC 与 Clang 的构建行为更统一，跨平台驱动和库的代码可能得到简化，以此减少重复和潜在错误，提高大型代码库的可读性。

然而，对于这一最新举措，众人看法不一。

有人觉得，这在象征意义上相当特殊，毕竟一个长期以来以“与 Microsoft 生态相对立”自居的内核，如今正式允许编译器采用 Visual Studio 风格的行为。

也有支持者认为，在网络、文件系统等性能关键区域，代码简洁性带来的效率提升值得这个权衡。

当然，并非所有人都对此感到兴奋——有开发者认为，引入“微软特有的行为”会破坏 Linux 长期坚持的原则。还有网友觉得——「依赖非标准特性，可能让坚持严格标准的构建变复杂，可能增加厂商锁定风险。」

目前这个补丁仍在观察中，最终还是得看 Linux 6.19 合并窗口的最新情况。

但如果补丁顺利通过审查，那么从 Linux 6.19 开始，内核将正式支持源自 Visual Studio 的 C 语言扩展——这在 15 年前的邮件列表讨论中，几乎是难以想象的事。

参考：

https://medium.com/@fedir_karasenko_14123/microsoft-c-extensions-are-coming-to-linux-6-19-20-years-after-the-first-proposal-a17878fc6e0b

https://news.ycombinator.com/item?id=45873625

来源：不秃头程序员