導讀：本文標題里的觀點很“刺激”，它來自國外一位 Swift 和 Rust 專家 Aria Beingessner，他近日撰寫了一篇文章《C 不再是一種編程語言》，在技術社區引起了熱議。

Beingessner 和他的朋友 Phantomderp 發現彼此在 C語言的某個方面都有著高度一致的意見——對 C ABI 感到憤怒，并試圖修復它們。盡管他們各自憤怒的原因不盡相同，但本文作者想要表達的是：“C 被提升到了一個具備聲望和權威的角色，它的統治是如此地絕對和永恒，以至于它完全扭曲了我們之間的對話方式。”“Rust 和 Swift 不能簡單地‘說’自己的母語或舒適的語言——它們必須怪異地模擬 C 的皮膚，并把自己包裹其中，使肉體以同樣的方式起伏。”

比喻雖尖銳，依據卻不無道理。幾乎任何程序要做任何有用或有趣的事情，它都必須在操作系統上運行。這意味著它必須與那個操作系統交互——而很多操作系統都是用 C 編寫的。因此，該語言必須與 C 代碼交互，這意味著它必須調用 C API。這是通過外部功能接口（FFI）完成的。換句話說，即使你從未用 C 編寫任何代碼，你也必須處理 C 變量、匹配 C 數據結構和布局、通過名稱和符號鏈接到 C 函數。這不僅適用于任何語言與操作系統的交互，也適用于從一種語言調用另一種語言。

雖然很多人都表示自己喜歡 C，但對文章的內容也是表達了認可和贊同。

更精確地說，這篇文章的核心并不是“C 不再是編程語言”，而是“C 不僅僅是一種編程語言”。InfoQ 對原文進行了翻譯，以饗讀者。以下內容節選自原文：

C 是編程通用語言，我們都必須學 C，因此 C 不再只是一種編程語言，它成了每一種通用編程語言都需要遵守的協議。

本文僅探討“C 由實現定義導致的難以捉摸的混亂”，這個讓所有人都不得不使用的協議已經變成了一個更大的噩夢。

首先，讓我們從技術的角度看看。你完成了新語言 Bappyscript 的設計，它對 Bappy Paws/Hooves/Fins 提供了一流的支持。這是一門神奇的語言，它將徹底改變人們的編程方式！

但現在，你需要用它做一些有用的事情，比如，接受用戶的輸入，或者輸出結果，或者任何可見的東西。如果你希望用你的語言編寫的程序成為優秀的公民，可以在主要的操作系統上很好地運行，那么你就需要與操作系統接口進行交互。我聽說，Linux 上的任何東西都“只是一個文件”，所以讓我們在 Linux 上打開一個文件。

OPEN(2)
NAME       open, openat, creat - open and possibly create a file
SYNOPSIS
       #include 
       int open(const char *pathname, int flags);       int open(const char *pathname, int flags, mode_t mode);
       int creat(const char *pathname, mode_t mode);
       int openat(int dirfd, const char *pathname, int flags);       int openat(int dirfd, const char *pathname, int flags, mode_t mode);
       /* Documented separately, in openat2(2): */       int openat2(int dirfd, const char *pathname,                   const struct open_how *how, size_t size);
   Feature Test Macro Requirements for glibc (see   feature_test_macros(7)):
       openat():           Since glibc 2.10:               _POSIX_C_SOURCE >= 200809L           Before glibc 2.10:_ATFILE_SOURCE

對不起，什么？這是 Bappyscript，不是 C。那 Linux 的 Bappyscript 接口在哪里？

你說 Linux 沒有 Bappyscript 接口是什么意思！？好吧，這是一種全新的語言，但你會添加一個，對吧？這時候你會想，我們好像必須使用他們給的東西。

我們將需要某種接口，使我們的語言能夠調用外部函數。外部函數接口，是的，FFI......然后你發現，什么，Rust，你也有 C 的 FFI？Swift 你也有嗎？甚至連 Python 也有？！

為了與主要的操作系統對話，每種語言都必須學會說 C 語言。然后，當它們需要相互對話時，也就都說起了 C 語言。

現在，C 語言成了編程通用語言。它不再僅僅是一種編程語言，還成了一種協議。

很明顯，幾乎每種語言都必須學會說 C 語言。那么，“說 C 語言”是什么意思？這是說要以 C 語言頭文件的方式描述接口的類型和函數，并以某種方式做一些事情：

• 匹配這些類型的布局；

• 用鏈接器做一些事情，將函數的符號解析為指針；

• 用適當的 ABI 來調用這些函數（比如把參數放在正確的寄存器中）。

然而這里有兩個問題：

• 你不能真的編寫一個 C 解析器；

• C 并沒有一個 ABI，甚至是定義好的類型布局。

真的，解析 C 語言基本上是不可能的。

“但是，等等！有很多工具可以讀取 C 語言的頭文件，比如 rust-bindgen！”

但還是不行：

bindgen 使用 libclang 來解析 C 和 C++ 頭文件。要修改 bindgen 搜索 libclang 的方式，請參閱 clang-sys 文檔。關于 bindgen 如何使用 libclang 的更多細節，請參閱 bindgen 用戶指南。

任何花了大量時間嘗試從語法上分析 C(++) 頭文件的人，很快就會說“啊，去他的”，并轉而用一個 C(++) 編譯器來做這件事。請記住，僅僅從語法上分析 C 頭文件是沒有意義的：你還需要解析 #includes、typedefs 和 macros 的。因此，現在你需要實現平臺所有的頭文件解析邏輯，并以某種方式找到與你所關注的環境相對應的 DEFINED 內容。

就拿 Swift 這個極端的例子來說吧。在 C 語言互操作和資源方面，它基本上擁有一切優勢。

該語言是由蘋果公司開發的，它有效地取代了 Objective-C，成為在蘋果平臺上定義和使用系統 API 的主語言。我認為，在這個過程中，它在 ABI 穩定性和設計方面比其他任何語言都更進一步。

它也是我見過的對 FFI 支持最好的語言之一。它可以本地導入 (Objective-)C(++) 頭文件，并生成一個漂亮的原生 Swift 接口，相關類型會自動“橋接”到 Swift 中對等的類型（通常是透明的，因為這些類型的 ABI 相同）。

Swift 的開發者同時也是蘋果公司 Clang 和 LLVM 項目的構建者和維護人。他們都是 C 語言及其衍生物方面的世界級專家。Doug Gregor 就是其中之一，以下是他對 C FFI 的看法：

看吧，即便是 Swift 也不愿意做這種事。（另外可以參見 Jordan Rose 和 John McCall 在 llvm 上的 PPT 去了解“Swift 為何采用這種方式”）。

那么，如果你無論如何也不想使用 C 編譯器在編譯時分析并解析頭文件，那么你要怎么做？你就要“手工翻譯”了！int64_t？還是說寫i64. long？......

好吧，這沒什么可大驚小怪的：出于“可移植性”考慮，C 語言中的整數類型被設計成大小不固定的。我們可以把賭注押在有點怪異的 CHAR_BIT 上，但我們還是無法知道 long 的大小和對齊方式。

”但是等等！每個平臺都有標準化的調用約定和 ABI！“

的確是有，而且它們通常定義了 C 語言中關鍵原語的布局！（而且，其中一些不僅僅定義了 C 類型的調用約定，參見 AMD64 SysV。）

但這里有一個棘手的問題：其架構中并沒有定義 ABI。操作系統也沒有。我們必須針對特定的目標三元組（target triple）做工作，比如“x86_64-pc-windows-gnu”（不要與“x86_64-pc-windows-msvc”弄混了）。

好吧，會有多少個這樣的目標三元組呢？

> rustc --print target-list
aarch64-apple-darwinaarch64-apple-iosaarch64-apple-ios-macabiaarch64-apple-ios-simaarch64-apple-tvos...

還有：

...armv7-unknown-linux-musleabiarmv7-unknown-linux-musleabihfarmv7-unknown-linux-uclibceabihf...

還有：

...x86_64-uwp-windows-gnux86_64-uwp-windows-msvcx86_64-wrs-vxworks
>_

這樣的目標三元組總共有176個。我原本打算都列出來，以增強視覺沖擊，但實在是太多了。

ABI 實在是太多了。而且，我們還沒有涉及到所有不同的調用約定，比如 stdcall vs fastcall 或者 aapcs vs aapcs-vfp！

至少，所有這些 ABI 和調用約定之類的東西肯定要以機器可讀的格式提供給大家使用：冗長的 PDF 文件。

好吧，至少對于特定的目標三原組，主要的 C 語言編譯器在 ABI 上達成了一致！當然，也有一些奇怪的 C 語言編譯器，如 clang 和 gcc-。

> abi-checker --tests ui128 --pairs clang_calls_gcc gcc_calls_clang
...
Test ui128::i128_val_in_0_perturbed_small        passedTest ui128::i128_val_in_1_perturbed_small        passedTest ui128::i128_val_in_2_perturbed_small        passedTest ui128::i128_val_in_3_perturbed_small        passedTest ui128::i128_val_in_0_perturbed_big          failed!test 57 arg3 field 0 mismatchcaller: [30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 3A, 3B, 3C, 3D, 3E, 3F]callee: [38, 39, 3A, 3B, 3C, 3D, 3E, 3F, 40, 41, 42, 43, 44, 45, 46, 47]Test ui128::i128_val_in_1_perturbed_big          failed!test 58 arg3 field 0 mismatchcaller: [30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 3A, 3B, 3C, 3D, 3E, 3F]callee: [38, 39, 3A, 3B, 3C, 3D, 3E, 3F, 40, 41, 42, 43, 44, 45, 46, 47]
...
392passed,60failed,0completelyfailed,8skipped

這是我在 x64 Ubuntu 20.04 上運行 FFI abi-checker 的結果。這是一個相當重要的、表現良好的平臺。這里測試的是一些非常令人厭煩的情況，即一些整型參數在兩個由 clang 和 gcc 編譯的靜態庫之間按值傳遞……而且失敗了！

甚至是 x64 linux 上的__int128ABI，clang 和 gcc 也未能達成一致。該類型是一個 gcc 擴展，但 AMD64 SysV ABI 在一個不錯的 PDF 文件里做了明確定義和說明。

我寫這個東西是為了檢查 rustc 中的錯誤，我并沒有指望發現，這兩個主要的 C 編譯器在最重要同時人們也最熟悉的 ABI 上存在不一致！

ABI 就是謊言。

因此，對 C 語言頭文件做語義解析是一個可怕的噩夢，只能由那個平臺的 C 編譯器來完成，即使你讓 C 編譯器告訴你類型以及如何理解注釋，但實際上，你仍然無法知道所有東西的大小 / 對齊方式 / 調用約定。

如何與那堆東西進行互操作呢？

你的第一個選項是完全投降，將你的語言與 C 語言進行靈魂綁定，可以采用以下任何一種方式：

• 用 C(++) 編寫編譯器 / 運行時，所以它無論如何都能說 C 語言。

• 讓你的“codegen”直接生成 C(++)，這樣用戶就需要一個 C 編譯器。

• 基于一個成熟的主流 C 編譯器（gcc 或 clang）構建自己的編譯器。

但也僅限于此，因為除非你的語言真的暴露了 unsigned long long，否則你就會繼承 C 的可移植性混亂。

于是，我們來到了第二個選項：撒謊、欺騙和偷竊。

如果這一切是一場躲不開的災難，那么還不如開始在自己的語言中手工翻譯類型和接口定義。這基本上就是我們在 Rust 中每天都在做的事情。是的，人們使用 rust-bindgen 之類的工具來自動化這個過程，但很多時候，還是需要檢查或手工調整那些定義，生命短暫，實在無法讓經過某人奇怪定制的 C 構建系統可移植。

嘿，Rust，在 x64 linux 上 intmax_t 是什么？

pubtypeintmax_t=i64;

嘿，Nim，在 x64 linux 上 long long 是什么？

clonglong{.importc:"longlong",nodecl.}=int64

很多代碼已經從各個環節中剔除了 C，并且已經開始對核心類型的定義進行硬編碼。畢竟，它們顯然只是平臺 ABI 的一部分！它們要做什么？改變 intmax_t 的大小嗎！？這顯然是一個破壞 ABI 的修改。

哦，對了，phantomderp 正在研究的那個東西又是什么？

我們談下為什么不能修改intmax_t，因為如果我們從longlong（64位整數）改為__int128_t（128 位整數），某些二進制文件就會無所適從，使用錯誤的調用約定/返回約定。但是，有沒有一種方法——如果代碼選用了——我們可以在新的應用程序中升級函數調用，而讓老的應用程序保持原樣？讓我們編寫一些代碼，測試一下透明別名可以為 ABI 帶來什么幫助。

是的，他們的文章真的寫得很好，解決了一些非常重要的實際問題，但是...... 編程語言如何處理這種變化？如何指定與哪個版本的 intmax_t 互操作？如果有一些 C 語言頭文件涉及到了 intmax_t，它使用哪個定義？

我們在討論 ABI 不同的平臺時使用的主要機制是目標三元組。你知道什么是目標三元組嗎？x86_64-unknown-linux-gnu。你知道都包括什么嗎？基本上涵蓋了過去 20 年里所有主要的桌面 / 服務器 Linux 發行版。表面上，你可以針對某個目標進行編譯，并得到一個在所有這些平臺上都能“正常工作”的二進制文件。但是，情況可能并非如此，比如有些程序在編譯時會默認 intmax_t 比 int64_t 大。

任何試圖做出這種改變的平臺是不是都會成為一個新的目標三元組？x86_64-unknown-linux-gnu2？如果任何針對 x86_64-unknown-linux-gnu 編譯的東西都可以在上面運行，這還不夠嗎？

”那又怎樣，難道 C 語言就永遠不會再改進了嗎？“

說不是也是，因為它糟糕的設計。

老實說，進行 ABI 兼容的修改可謂是一種藝術形式。這項工作的一部分是準備。如果你準備好了，做不破壞 ABI 的修改就會簡單很多。

正如 phantomderp 的文章所指出的那樣，像 glibc（g 是 x86_64-unknown-linux-gnu 中的 gnu）早就意識到了這一點，并使用符號版本化這樣的機制來更新簽名和 API，同時為任何針對舊版本的編譯保留舊版本。

因此，如果有個方法 int32_t my_rad_symbol(int32_t)，你告訴編譯器將其導出為 my_rad_symbol_v1，那么任何針對你所提供的頭文件進行編譯的人，都會在代碼中寫上 my_rad_symbol，但會鏈接到 my_rad_symbol_v1。

然后，當你確定實際應該使用 int64_t 時，可以把 int64_t my_rad_symbol(int64_t) 當作 my_rad_symbol_v2，但仍然保留舊的定義 my_rad_symbol_v1。任何人在針對你的頭文件進行編譯時，如果是針對新版本就使用符號 v2，而針對舊版本則繼續使用 v1！

但仍然有一個兼容性問題：任何針對新的頭文件所做的編譯都不能與舊版本的庫進行鏈接！庫的 v1 版本根本沒有 v2 符號。所以，如果你想要熱門的新功能，就需要接受與舊有系統不兼容的事實。

不過，這并不是什么大問題，只是會讓平臺供應商感到難過，因為沒有人能夠立即使用他們花了這么多時間做出來的東西。你推出了一個閃亮的新特性，卻要放在手里等數年的時間，等到大家認為它變得足夠普及 / 成熟，愿意依賴它并打破對舊平臺的支持（或者愿意為它實現動態檢查和回退）。

如果你想讓人們立即升級，那么就是向前兼容的問題了。這就需要讓舊版本能夠適應它們完全沒有概念的新特性。

好了，除了修改函數的簽名，我們還可以修改什么？我們可以修改類型布局嗎？

可以！但也不可以！這取決于你暴露類型的方式。

C 語言真正奇妙的其中一個功能是，它讓你可以區分布局已知的類型和布局未知的類型。如果你只在 C 語言的頭文件中前向聲明一個類型，那么任何與該類型交互的用戶代碼都無法知道該類型的布局，而必須一直通過指針不透明地對它做處理。

所以你可以開發一個像 MyRadType*make_val() 和 use_val(MyRadType) 這樣的 API，然后利用同樣的符號版本化技巧來暴露 make_val_v1 和 use_val_v1，任何時候你想修改這個布局，都要在與該類型交互的所有東西上修改版本。同樣地，你得保留 MyRadTypeV1、MyRadTypeV2 和一些類型定義，以確保人們使用“正確”的類型。

很好，我們可以改變不同版本之間的類型布局！對嗎？嗯，大多數時候是這樣。

如果有多個東西基于你的庫構建，它們在類型不透明的情況下相互調用，就會出現糟糕的情況：

• lib1：開發一個 API，使用類型 MyRadType* 調用 use_val；

• lib2：調用 make_val ，并將結果傳給 lib1。

如果 lib1 和 lib2 是基于庫的不同版本進行編譯的，那么 make_val_v1 就會被傳遞給 use_val_v2！這時，你有兩個選擇來處理這個問題：

1. 禁止這樣做，警告那些這樣做的人，令人傷心。

2. 以一種向前兼容的方式設計 MyRadType，這樣混用就沒問題了。

實現向前兼容常用的技巧有：

• 保留未使用的字段供未來版本使用。

• MyRadType 的所有版本都有一個共同的前綴，讓你可以“檢查”所使用的版本。

• 有大小自適應的字段，這樣舊版本可以“跳過”新增部分。

  案例分析：MINIDUMP_HANDLE_DATA

微軟確實是向前兼容的大師，他們甚至讓他們真正關心的東西在不同的架構之間保持布局兼容。我最近遇到的一個例子是 Minidumpapiset.h 中的 MINIDUMP_HANDLE_DATA_STREAM。

這個 API 描述了一個版本化的值列表。該列表以這種類型開始：

typedef struct _MINIDUMP_HANDLE_DATA_STREAM {    ULONG32 SizeOfHeader;    ULONG32 SizeOfDescriptor;    ULONG32 NumberOfDescriptors;    ULONG32 Reserved;}MINIDUMP_HANDLE_DATA_STREAM,*PMINIDUMP_HANDLE_DATA_STREAM;

其中：

• SizeOfHeader 是 MINIDUMP_HANDLE_DATA_STREAM 本身的大小。如果需要在末尾添加更多的字段，那也沒關系，因為舊版本可以使用這個值來檢測頭的“版本”，并跳過任何它們不識別的字段。

• SizeOfDescriptor 是數組中每個元素的大小。這也是為了讓你知道元素是什么“版本”，你可以跳過不知道的字段。

• NumberOfDescriptors 是數組長度。

• Reserved 是一個保留字段（Minidumpapiset.h 非常嚴謹，從不使用任何填充字節，因為填充字節的值未定，而且是一種序列化的二進制文件格式。我希望他們添加這個字段是為了使結構的大小是 8 的倍數，這樣就不會有數組元素是否需要在頭之后填充的問題了。哇，這才是認真對待兼容性！)

事實上，微軟使用這種版本化方案是有原因的，他們定義了兩個版本的數組元素：

typedef struct _MINIDUMP_HANDLE_DESCRIPTOR {    ULONG64 Handle;    RVA TypeNameRva;    RVA ObjectNameRva;    ULONG32 Attributes;    ULONG32 GrantedAccess;    ULONG32 HandleCount;    ULONG32 PointerCount;} MINIDUMP_HANDLE_DESCRIPTOR, *PMINIDUMP_HANDLE_DESCRIPTOR;
typedef struct _MINIDUMP_HANDLE_DESCRIPTOR_2 {    ULONG64 Handle;    RVA TypeNameRva;    RVA ObjectNameRva;    ULONG32 Attributes;    ULONG32 GrantedAccess;    ULONG32 HandleCount;    ULONG32 PointerCount;    RVA ObjectInfoRva;    ULONG32 Reserved0;} MINIDUMP_HANDLE_DESCRIPTOR_2, *PMINIDUMP_HANDLE_DESCRIPTOR_2;
// 最新MINIDUMP_HANDLE_DESCRIPTOR定義。typedef MINIDUMP_HANDLE_DESCRIPTOR_2 MINIDUMP_HANDLE_DESCRIPTOR_N;typedefMINIDUMP_HANDLE_DESCRIPTOR_N*PMINIDUMP_HANDLE_DESCRIPTOR_N;

關于這些結構的實際細節，有幾個比較有趣的地方：

• 對它的修改只是在末尾添加字段；

• “最后一個”有類型定義；

• 保留一些 Maybe Padding（RVA 是 ULONG32 類型）。

在向前兼容性方面，微軟絕對是一頭堅不可摧的巨獸。他們對填充如此謹慎，甚至在 32 位和 64 位之間采用了相同的布局！（實際上，這非常重要，因為你希望一個架構的小型轉儲文件處理器能夠處理每個架構的小型轉儲文件。）

好吧，至少它真的很健壯，如果你按照它的規則來，通過引用進行操作，并使用 size 字段。

但至少可以玩下去。只是在某些時候，你不得不說“你的用法不對”。微軟可能不會這么說，他們只會做一些可怕的事。

案例分析：jmp_buf

我對這種情況不是很熟悉，但在研究 glibc 歷史上的破壞性修改時，我在 lwn 上看到了這篇很棒的文章：glibc s390 ABI 的破壞性修改。我認為這篇文章比較準確。

事實證明，glibc 曾經破壞過類型的 ABI，至少在 s390 上是這樣。根據這篇文章的描述，它造成了混亂。

特別地，他們改變了 setjmp/longjmp 使用的狀態保存類型（即 jmp_buf）的布局。看吧，他們并不是十足的傻瓜。他們知道這是一個破壞 ABI 的修改，所以他們負責任地做了符號版本化。

但是，jmp_buf 并不是一個不透明類型。有些東西內聯地存儲了這個類型的實例，比如 Perl 的運行時。不用說，這個相比之下不是很容易理解的類型已經滲透到許多二進制文件中去了，最終的結論是，Debian 的所有東西都需要重新編譯。

這篇文章甚至討論了對 libc 進行版本升級以應對這種情況的可能性：

在像 Debian 這樣的混合 ABI 環境中，SO 名稱的改變（SO name bump）會導致兩個 libc 被加載并競爭相同的符號命名空間，而解析（以及 ABI 選擇）由 ELF 插值和作用域規則決定。這真是一場噩夢。這可能是一個比告訴所有人重新構建并回歸正常軌道更糟糕的解決方案。

（這篇文章很不錯，強烈建議您讀一下。）

在我看來，未必。和 jmp_buf 一樣，它不是一個不透明類型，也就是說，它被大量的隨機結構內聯，被其他大量的語言和編譯器視為一個特定的表示，并且可能存在于大量的公共接口中，而這些接口不在 libc、linux、甚至發行版維護者的控制之下。

當然，libc 可以適當地使用符號版本化技巧，使其 API 可以適應新的定義，但是，改變一個基本數據類型（像 intmax_t）的大小，會在更大的平臺生態系統中引發混亂。

如果有人能夠證明我是錯的，我會很高興，但據我所知，做出這樣的改變需要一個新的目標三元組，并且不允許任何為舊 ABI 構建的二進制文件 / 庫在這個新三元組上運行。當然，你可以這樣做，但我并不羨慕任何做了這些工作的發行版。

即使如此，還有 x64 int 的問題：它是非常基本的類型，而且長期以來大小從沒變過，無數的應用程序可能對它做了無法察覺的假設。這就是為什么 int 在 x64 上是 32 位的，盡管它“應該”是 64 位的：int 長期以來都是 32 位，以至于將軟件升級到新的大小完全無望，盡管它是一個全新的架構和目標三元組。

我也希望我的觀點是錯的。如果 C 語言只是一種獨立的編程語言，那我們就可以毫無顧慮地往前沖。但它實際上不是了，它是一個協議，還是一個糟糕的協議，而我們還必須要用它。

很遺憾，C，你征服了世界，但或許不再擁有往昔的美好。

原文鏈接：https://gankra.github.io/blah/c-isnt-a-language