“C不再是一種編程語言”

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

現(xiàn)在，C 語言成了編程通用語言。它不再僅僅是一種編程語言，還成了一種協(xié)議。

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

• 匹配這些類型的布局；

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

• 用適當(dāng)?shù)?ABI 來調(diào)用這些函數(shù)（比如把參數(shù)放在正確的寄存器中）。

然而這里有兩個問題：

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

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

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

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

但還是不行：

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

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

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

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

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

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

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

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

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

”但是等等！每個平臺都有標(biāo)準(zhǔn)化的調(diào)用約定和 ABI！“

的確是有，而且它們通常定義了 C 語言中關(guān)鍵原語的布局?。ǘ?，其中一些不僅僅定義了 C 類型的調(diào)用約定，參見 AMD64 SysV。）

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

好吧，會有多少個這樣的目標(biāo)三元組呢？

> 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
>_

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

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

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

好吧，至少對于特定的目標(biāo)三原組，主要的 C 語言編譯器在 ABI 上達(dá)成了一致！當(dāng)然，也有一些奇怪的 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 的結(jié)果。這是一個相當(dāng)重要的、表現(xiàn)良好的平臺。這里測試的是一些非常令人厭煩的情況，即一些整型參數(shù)在兩個由 clang 和 gcc 編譯的靜態(tài)庫之間按值傳遞……而且失敗了！

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

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

ABI 就是謊言。

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

如何與那堆東西進(jìn)行互操作呢？

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

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

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

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

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

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

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

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

pubtypeintmax_t=i64;

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

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

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

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

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

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

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

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

”那又怎樣，難道 C 語言就永遠(yuǎn)不會再改進(jìn)了嗎？“

說不是也是，因為它糟糕的設(shè)計。

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

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

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

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

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

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

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

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

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

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

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

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

如果有多個東西基于你的庫構(gòu)建，它們在類型不透明的情況下相互調(diào)用，就會出現(xiàn)糟糕的情況：

• lib1：開發(fā)一個 API，使用類型 MyRadType* 調(diào)用 use_val；

• lib2：調(diào)用 make_val ，并將結(jié)果傳給 lib1。

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

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

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

實現(xiàn)向前兼容常用的技巧有：

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

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

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

  案例分析：MINIDUMP_HANDLE_DATA

微軟確實是向前兼容的大師，他們甚至讓他們真正關(guān)心的東西在不同的架構(gòu)之間保持布局兼容。我最近遇到的一個例子是 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 本身的大小。如果需要在末尾添加更多的字段，那也沒關(guān)系，因為舊版本可以使用這個值來檢測頭的“版本”，并跳過任何它們不識別的字段。

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

• NumberOfDescriptors 是數(shù)組長度。

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

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

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;

關(guān)于這些結(jié)構(gòu)的實際細(xì)節(jié)，有幾個比較有趣的地方：

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

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

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

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

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

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

案例分析：jmp_buf

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

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

特別地，他們改變了 setjmp/longjmp 使用的狀態(tài)保存類型（即 jmp_buf）的布局?？窗?，他們并不是十足的傻瓜。他們知道這是一個破壞 ABI 的修改，所以他們負(fù)責(zé)任地做了符號版本化。

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

這篇文章甚至討論了對 libc 進(jìn)行版本升級以應(yīng)對這種情況的可能性：

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

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

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

當(dāng)然，libc 可以適當(dāng)?shù)厥褂梅柊姹净记?，使?API 可以適應(yīng)新的定義，但是，改變一個基本數(shù)據(jù)類型（像 intmax_t）的大小，會在更大的平臺生態(tài)系統(tǒng)中引發(fā)混亂。

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

即使如此，還有 x64 int 的問題：它是非?；镜念愋停议L期以來大小從沒變過，無數(shù)的應(yīng)用程序可能對它做了無法察覺的假設(shè)。這就是為什么 int 在 x64 上是 32 位的，盡管它“應(yīng)該”是 64 位的：int 長期以來都是 32 位，以至于將軟件升級到新的大小完全無望，盡管它是一個全新的架構(gòu)和目標(biāo)三元組。

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

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

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