ISO C 的幻象：可移植性、擴充功能與編譯器的掙扎"}]

對於任何投入大量時間編寫 C 語言的人來說，ISO C 標準通常被視為一種理論上的理想，而非實際的現實。雖然標準為可移植性提供了基準，但絕大多數現實世界的 C 程式碼庫都依賴非標準行為、編譯器擴充功能以及平台特定的技巧，以實現效能、與硬體互動，或僅僅是為了規避工具鏈中現有的錯誤。

這種緊張關係為替代 C 編譯器的開發者創造了一個艱鉅的環境。為了具備實用性，編譯器不能僅僅遵守 ISO 標準；它必須在預處理器守衛（preprocessor guards）和隱含假設的雷區中穿行，而這些假設往往偏向少數幾種主流編譯器。

守門人：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。這突顯了一個系統性問題：可移植性往往是由針對特定編譯器名稱的顯式檢查，而非針對特定功能的檢查來把關的。

Inline 函數的複雜性

Inline 函數是另一個存在顯著摩擦的領域。從前 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 標頭檔使用了一套分層的偵測系統來進行位元組交換（byteswapping）。如果編譯器不是 GCC 或 Clang，它可能會退回到基於 ISA 巨集的擴充 inline assembly，即使編譯器提供了必要的內建函數（builtins）。這假設了任何針對 x86_64 的編譯器也必須支援 GCC 風格的 inline assembly。

編譯器開發者的困境

在構建獨立的 C 編譯器時，開發者通常面臨四種處理這些不相容性的選項：

  1. 上游修補 (Upstream Patching): 嘗試在原始函式庫中修復問題。由於程式碼量龐大且維護者對於增加對冷門編譯器的支援往往不情願，這通常是一場注定失敗的戰鬥。
  2. 普及度 (Popularity): 增加使用者群體，直到開發者有動力為新編譯器增加顯式支援。
  3. 下游修補 (Downstream Patching): 為編譯器打算支援的函式庫分發修補程式。這是短期內最簡單的修 fix，但無法擴展。
  4. 「偽裝」策略 (The "Impersonation" Strategy): 假裝成特定版本的 GCC。

第四個選項是實現廣泛相容性的最現實路徑。例如，Clang 定義了 __GNUC__=4 以聲稱與 GCC 4.2.1 相容。這使得 Clang 能夠通過大多數 #ifdef __GNUC__ 檢查，而不會觸發最近的、且可能不受支援的 GNU 擴充功能。然而，這會導致一場永無止境的追趕賽，因為編譯器必須實作每一個程式碼庫預於該特定 GCC 版本所期望的擴充功能。

邁向更好的標準

目前的 C 可移植性現狀是 GCC/Clang 雙頭壟斷的結果。社群共識建議，未來的路徑在於功能測試巨集（例如 __has_builtin, __has_attribute），而非編譯器名稱守衛。透過向編譯器查詢其具備何種能力而非其身份，程式碼庫可以變得真正可移植於任何支援所需功能的實作方式上。

直到那時，可移植性仍然是一項艱鉅的任務，必須透過逆向工程來推導主流工具鏈的假設，使得實現一個真正遵守標準的 C 生態系統成為一種不切實際的罕見現象。

Sources