ISO C 的幻象：可移植性、扩展与编译器的挣扎

对于任何投入大量时间编写 C 语言的人来说，ISO C 标准通常被视为一种理论上的理想，而非实际的现实。虽然标准为可移植性提供了基准，但绝大多数现实世界的 C 代码库都依赖于非标准行为、编译器扩展以及特定平台的补丁，以实现性能、与硬件交互，或者仅仅是为了规避工具链中现有的 bug。

这种紧张关系为替代 C 编译器的开发者创造了一个令人生畏的环境。为了发挥作用，编译器不能仅仅遵循 ISO 标准；它必须穿梭于预处理器保护符和隐式假设的雷区之中，而这些假设往往偏向于少数几种主流编译器。

守门人：glibc 与系统头文件

任何新 C 编译器的第一个障碍就是系统的 C 库头文件。在 GNU/Linux 上，这意味着要处理 glibc。虽然 glibc 试图与非 GCC 编译器保持兼容，但其实现往往非常脆弱。

一个显著的例子是在 sys/epoll.h 中为 struct epoll_event 使用了 __attribute__((packed))。由于该属性会改变 64 位系统上的结构体内存布局，因此它对于 ABI 兼容性至关重要。然而，glibc 的 sys/cdefs.h 经常在编译器未被识别为 GCC、Clang 或 TCC 时，将 __attribute__(xyz) 定义为空宏：

#if !(defined __GNUC__ || defined __clang__ || defined __TINYC__)
# define __attribute__(xyz)     /* Ignore */
#endif

如果你的编译器不在该列表中，packed 属性就会被忽略，结构体布局随之改变，最终生成的二进制文件会破坏 ABI。这凸显了一个系统性问题：可移植性往往是由对特定编译器名称的显式检查，而非对特定功能的检查来把关的。

内联函数的复杂性

内联函数是另一个存在显著摩擦的领域。从前 C99 时期的非标准 GCC 行为向 C99 标准的转变，导致了在如何处理 inline 和 extern inline 方面出现了分歧。

OpenBSD 的 libc 头文件使用了一个名为 __only_inline 的宏来提供函数的优化版本。在非 GNU 编译器上，这通常默认为 static 链接，这可能会导致冲突的链接错误。虽然 OpenBSD 提供了一个 _ANSI_LIBRARY 宏来省略这些定义，但它迫使开发者为了基本的编译而不得不牺牲优化。

这种碎片化非常严重，以至于像 Gnulib 这样的项目开发了庞大且复杂的预处理器块，用以检测 GCC 的确切版本或特定的操作系统（Apple, FreeBSD, DragonFly）来决定是否使用 extern inline 或 static 链接。正如社区讨论中所见，这种“nutburger nonsense”是任何实现 C 兼容性前端的人都会遇到的共同痛点。

特定平台的假设：Android 与 SDL

除了核心 libc 之外，第三方库和特定平台的实现进一步复杂化了局面：

  • Android 的 Bionic: 与大多数基于 Linux 的系统不同，Bionic 大量假设使用 Clang。它充斥着 Clang 特有的扩展，例如用于空值检查的 _Nonnull 和 _Null_unspecified。虽然这些可以通过 #defined 消除，但这表明了即使在“C 生态系统”内部，也不存在单一的事实来源。
  • SDL: SDL_endian.h 头文件使用分层检测系统来进行字节序转换。如果编译器不是 GCC 或 Clang，它可能会回退到基于 ISA 宏（如 __x86_64__）的扩展内联汇编，即使编译器提供了必要的内置函数。这假设了任何针对 x86_64 的编译器也必须支持 GCC 风格的内联汇编。

编译器开发者的困境

在构建独立的 C 编译器时，开发者通常面临四种处理这些不兼容性的方案：

  1. 上游补丁: 尝试修复原始库中的问题。由于代码量巨大且维护者不太愿意为晦涩的编译器添加支持，这通常是一场注定失败的战斗。
  2. Popularity (流行度): 增加用户群，直到开发者们有动力为新编译器添加显式支持。
  3. 下游补丁: 为编译器打算支持的库分发补丁。这是短期内最简单的修复方法，但无法规模化。
  4. “模仿”策略: 假装成特定版本的 GCC。

第四种方案是实现广泛兼容性的最现实路径。例如，Clang 定义了 __GNUC__=4 以声称与 GCC 4.2.1 兼容。这使得 Clang 能够通过大多数 #ifdef __GNUC__ 检查，而不会触发最近的、且可能不受支持的 GNU 扩展。然而，这会导致一场永无止境的追赶游戏，因为编译器必须实现代码库所期望从该特定 GCC 版本中获得的所有扩展。

迈向更好的标准

目前的 C 可移植性现状是 GCC/Clang 双头垄断的结果。社区共识表明，未来的路径在于特征测试宏（例如 __has_builtin, __has_attribute），而非编译器名称保护符。通过向编译器查询其特定的能力而非其身份，代码库可以实现真正的可移植性，跨越任何支持所需功能的实现。

直到那时，可移植性的负担仍然是一项艰巨的任务，即逆向工程主流工具链的假设，这使得实现一个真正遵循标准的 C 生态系统成为了一个难以实现的罕见现象。

Sources