作者｜Aria Beingessner
翻譯｜平川
本文标題裡的觀點很“刺激”，它來自國外一位 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 上打開一個檔案。
對不起，什麼？這是 Bappyscript，不是 C。那 Linux 的 Bappyscript 接口在哪裡？
你說 Linux 沒有 Bappyscript 接口是什麼意思！？好吧，這是一種全新的語言，但你會添加一個，對吧？這時候你會想，我們好像必須使用他們給的東西。
我們将需要某種接口，使我們的語言能夠調用外部函數。外部函數接口，是的，FFI......然後你發現，什麼，Rust，你也有 C 的 FFI？Swift 你也有嗎？甚至連 Python 也有？！
為了與主要的作業系統對話，每種語言都必須學會說 C 語言。然後，當它們需要互相對話時，也就都說起了 C 語言。
現在，C 語言成了程式設計通用語言。它不再僅僅是一種程式設計語言，還成了一種協定。
與 C 互動涉及哪些方面？
很明顯，幾乎每種語言都必須學會說 C 語言。那麼，“說 C 語言”是什麼意思？這是說要以 C 語言頭檔案的方式描述接口的類型和函數，并以某種方式做一些事情：
比對這些類型的布局；
用連結器做一些事情，将函數的符号解析為指針；
用适當的 ABI 來調用這些函數（比如把參數放在正确的寄存器中）。
然而這裡有兩個問題：
你不能真的編寫一個 C 解析器；
C 并沒有一個 ABI，甚至是定義好的類型布局。
你不能真的解析一個 C 頭檔案
真的，解析 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 實際上并沒有 ABI
好吧，這沒什麼可大驚小怪的：出于“可移植性”考慮，C 語言中的整數類型被設計成大小不固定的。我們可以把賭注押在有點怪異的 CHAR_BIT 上，但我們還是無法知道long的大小和對齊方式。
”但是等等！每個平台都有标準化的調用約定和 ABI！“
的确是有，而且它們通常定義了 C 語言中關鍵原語的布局！（而且，其中一些不僅僅定義了 C 類型的調用約定，參見 AMD64 SysV。）
但這裡有一個棘手的問題：其架構中并沒有定義 ABI。作業系統也沒有。我們必須針對特定的目标三元組（target triple）做工作，比如“x86_64-pc-windows-gnu”（不要與“x86_64-pc-windows-msvc”弄混了）。
好吧，會有多少個這樣的目标三元組呢？
還有：
這樣的目标三元組總共有176個。我原本打算都列出來，以增強視覺沖擊，但實在是太多了。
ABI 實在是太多了。而且，我們還沒有涉及到所有不同的調用約定，比如 stdcall vs fastcall 或者 aapcs vs aapcs-vfp！
至少，所有這些 ABI 和調用約定之類的東西肯定要以機器可讀的格式提供給大家使用：冗長的 PDF 檔案。
好吧，至少對于特定的目标三原組，主要的 C 語言編譯器在 ABI 上達成了一緻！當然，也有一些奇怪的 C 語言編譯器，如 clang 和 gcc-。
這是我在 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(++) 編寫編譯器 / 運作時，是以它無論如何都能說 C 語言。
讓你的“codegen”直接生成 C(++)，這樣使用者就需要一個 C 編譯器。
基于一個成熟的主流 C 編譯器（gcc 或 clang）建構自己的編譯器。
但也僅限于此，因為除非你的語言真的暴露了unsigned long long，否則你就會繼承 C 的可移植性混亂。
于是，我們來到了第二個選項：撒謊、欺騙和偷竊。
如果這一切是一場躲不開的災難，那麼還不如開始在自己的語言中手工翻譯類型和接口定義。這基本上就是我們在 Rust 中每天都在做的事情。是的，人們使用 rust-bindgen 之類的工具來自動化這個過程，但很多時候，還是需要檢查或手工調整那些定義，生命短暫，實在無法讓經過某人奇怪定制的 C 建構系統可移植。
嘿，Rust，在 x64 linux 上intmax_t是什麼？
嘿，Nim，在 x64 linux 上long long是什麼？
很多代碼已經從各個環節中剔除了 C，并且已經開始對核心類型的定義進行寫死。畢竟，它們顯然隻是平台 ABI 的一部分！它們要做什麼？改變intmax_t的大小嗎！？這顯然是一個破壞 ABI 的修改。
哦，對了，phantomderp 正在研究的那個東西又是什麼？
我們談下為什麼不能修改intmax_t，因為如果我們從 long long（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編譯的東西都可以在上面運作，這還不夠嗎？
修改簽名而又不破壞 ABI
”那又怎樣，難道 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 符号。是以，如果你想要熱門的新功能，就需要接受與舊有系統不相容的事實。
不過，這并不是什麼大問題，隻是會讓平台供應商感到難過，因為沒有人能夠立即使用他們花了這麼多時間做出來的東西。你推出了一個閃亮的新特性，卻要放在手裡等數年的時間，等到大家認為它變得足夠普及 / 成熟，願意依賴它并打破對舊平台的支援（或者願意為它實作動态檢查和回退）。
如果你想讓人們立即更新，那麼就是向前相容的問題了。這就需要讓舊版本能夠适應它們完全沒有概念的新特性。
修改類型而不破壞 ABI
好了，除了修改函數的簽名，我們還可以修改什麼？我們可以修改類型布局嗎？
可以！但也不可以！這取決于你暴露類型的方式。
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！這時，你有兩個選擇來處理這個問題：
禁止這樣做，警告那些這樣做的人，令人傷心。
以一種向前相容的方式設計MyRadType，這樣混用就沒問題了。
實作向前相容常用的技巧有：
保留未使用的字段供未來版本使用。
MyRadType 的所有版本都有一個共同的字首，讓你可以“檢查”所使用的版本。
有大小自适應的字段，這樣舊版本可以“跳過”新增部分。
案例分析：MINIDUMP_HANDLE_DATA
微軟确實是向前相容的大師，他們甚至讓他們真正關心的東西在不同的架構之間保持布局相容。我最近遇到的一個例子是Minidumpapiset.h中的 MINIDUMP_HANDLE_DATA_STREAM。
這個 API 描述了一個版本化的值清單。該清單以這種類型開始：
其中：
SizeOfHeader是 MINIDUMP_HANDLE_DATA_STREAM 本身的大小。如果需要在末尾添加更多的字段，那也沒關系，因為舊版本可以使用這個值來檢測頭的“版本”，并跳過任何它們不識别的字段。
SizeOfDescriptor是數組中每個元素的大小。這也是為了讓你知道元素是什麼“版本”，你可以跳過不知道的字段。
NumberOfDescriptors是數組長度。
Reserved是一個保留字段（Minidumpapiset.h非常嚴謹，從不使用任何填充位元組，因為填充位元組的值未定，而且是一種序列化的二進制檔案格式。我希望他們添加這個字段是為了使結構的大小是 8 的倍數，這樣就不會有數組元素是否需要在頭之後填充的問題了。哇，這才是認真對待相容性！)
事實上，微軟使用這種版本化方案是有原因的，他們定義了兩個版本的數組元素：
關于這些結構的實際細節，有幾個比較有趣的地方：
對它的修改隻是在末尾添加字段；
“最後一個”有類型定義；
保留一些 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 插值和作用域規則決定。這真是一場噩夢。這可能是一個比告訴所有人重新建構并回歸正常軌道更糟糕的解決方案。
（這篇文章很不錯，強烈建議您讀一下。）
真的能修改 intmax_t？
在我看來，未必。和jmp_buf一樣，它不是一個不透明類型，也就是說，它被大量的随機結構内聯，被其他大量的語言和編譯器視為一個特定的表示，并且可能存在于大量的公共接口中，而這些接口不在 libc、linux、甚至發行版維護者的控制之下。
當然，libc 可以适當地使用符号版本化技巧，使其 API 可以适應新的定義，但是，改變一個基本資料類型（像intmax_t）的大小，會在更大的平台生态系統中引發混亂。
如果有人能夠證明我是錯的，我會很高興，但據我所知，做出這樣的改變需要一個新的目标三元組，并且不允許任何為舊 ABI 建構的二進制檔案 / 庫在這個新三元組上運作。當然，你可以這樣做，但我并不羨慕任何做了這些工作的發行版。
即使如此，還有 x64 int 的問題：它是非常基本的類型，而且長期以來大小從沒變過，無數的應用程式可能對它做了無法察覺的假設。這就是為什麼 int 在 x64 上是 32 位的，盡管它“應該”是 64 位的：int 長期以來都是 32 位，以至于将軟體更新到新的大小完全無望，盡管它是一個全新的架構和目标三元組。
我也希望我的觀點是錯的。如果 C 語言隻是一種獨立的程式設計語言，那我們就可以毫無顧慮地往前沖。但它實際上不是了，它是一個協定，還是一個糟糕的協定，而我們還必須要用它。
很遺憾，C，你征服了世界，但或許不再擁有往昔的美好。