Rust 提供外部函式介面（FFI）機制，允許與其他語言（例如 C）的程式碼互動。由於 FFI 涉及跨語言邊界，因此必須謹慎管理資料型別和記憶體分配，避免潛在的錯誤。Rust 預設以 C 語言作為 FFI 的目標語言，使用 extern "C" 關鍵字宣告外部 C 函式。跨 FFI 界限時，Rust 的記憶體安全機制失效，因此需要特別注意函式簽名、資料型別和連線性，確保 Rust 和 C 程式碼之間的正確互動。例如，使用 std::os::raw::c_int 來表示 C 的 int 型別，並使用 unsafe 區塊來標記 FFI 函式的呼叫。為了確保記憶體安全，建議將不安全的 FFI 程式碼封裝在安全的 Rust 函式中，並使用 RAII 模式管理資源，例如使用 Box::into_raw 和 Box::from_raw 來管理 C 分配的記憶體。此外，使用 #[repr(C)] 屬性可以確保 Rust 資料結構的佈局與 C 相容，避免資料存取錯誤。
控制跨 FFI 界限的內容
即使 Rust 擁有全面的標準函式庫和蓬勃發展的 crate 生態系統，仍然有大量非 Rust 程式碼存在於世界上。為瞭解決這個問題，Rust 提供了一種稱為 FFI（外部函式介面）的機制，允許 Rust 程式碼與其他語言編寫的程式碼和資料結構進行互動操作。這使得開發人員可以使用現有的函式庫和框架，即使它們不是用 Rust 編寫的。
預設目標：C 語言
Rust 的預設目標語言是 C，因為 C 是一個相對低階別的語言，能夠作為不同語言之間的共同橋樑。這也意味著 Rust 的 FFI 機制主要針對 C 進行最佳化。透過使用 extern "C" 關鍵字，Rust 程式碼可以宣告外部 C 函式，並在編譯時連線到相應的 C 程式碼。
控制跨界內容
當使用 FFI 時，Rust 的記憶體安全保證和保護機制會失效，因此 FFI 程式碼被視為不安全程式碼。為了避免潛在的風險，開發人員需要小心控制跨 FFI 界限的內容，包括：
- 函式簽名：確保外部函式的簽名正確無誤，包括引數型別和傳回型別。
- 資料型別：確保資料型別在不同語言之間的一致性，例如使用
std::os::raw::c_int來表示 C 的int型別。 - 連線性：確保 Rust 程式碼能夠連線到外部 C 程式碼，可能需要使用
link屬性或Cargo.toml中的links欄位。
實際應用
以下是一個簡單的範例，展示如何使用 FFI 來呼叫 C 函式：
use std::os::raw::c_int;
extern "C" {
pub fn add(x: c_int, y: c_int) -> c_int;
}
fn main() {
let result = unsafe { add(2, 3) };
println!("Result: {}", result);
}
在這個範例中，Rust 程式碼聲明瞭一個外部 C 函式 add，並在 main 函式中呼叫它。注意到 add 函式被標記為 unsafe，因為它涉及到跨 FFI 界限的操作。
控制跨 FFI 界限的內容
在使用外部函式介面（FFI）時，需要注意一些潛在的問題。首先，FFI 函式的使用是自動標記為不安全的，因此需要使用 unsafe 區塊來包裝它們。
let x = unsafe { add(1, 1) };
另一個需要注意的是 C 的 int 型別，它在 Rust 中被代表為 std::os::raw::c_int。雖然大多數情況下，C 的 int 型別和 Rust 的 std::os::raw::c_int 型別的大小相同，但為了避免潛在的問題，應該盡可能使用有大小的型別，例如 <stdint.h> 中定義的 uint32_t。
// C code
uint32_t add(uint32_t a, uint32_t b) {
return a + b;
}
// Rust code
extern "C" {
fn add(a: u32, b: u32) -> u32;
}
fn main() {
let x = unsafe { add(1, 1) };
}
最後，C 程式碼和 Rust 程式碼需要完全匹配，否則可能會導致無法預測的行為。為了避免這個問題，可以使用 bindgen 工具來自動生成 Rust 程式碼。
名稱修飾
編譯語言通常支援分離編譯，這意味著程式的不同部分可以被編譯成機器碼的獨立塊（物件檔），然後可以被鏈結成一個完整的程式。鏈結步驟基本上是一個「連線點」的操作：一些物件檔提供函式和變數的定義，而其他物件檔有佔位符號，表示它們期待從其他物件檔中使用定義，但是在編譯時不可用。鏈結器將這些物件檔結合起來，確保編譯碼中的任何佔位符號都被替換為對應的具體定義。
鏈結器透過名稱修飾來執行這些佔位符號和定義之間的關聯。名稱修飾是一種機制，透過它，鏈結器可以將一個名稱對映到一個唯一的識別符號。這樣就可以確保程式中沒有名稱衝突。
然而，C++ 的引入導致了一個問題，因為 C++ 允許使用相同名稱的覆寫定義。為瞭解決這個問題，C++ 使用了一種稱為名稱修飾的機制來將名稱對映到唯一的識別符號。
// C++ code
class MyClass {
public:
void myFunction();
};
void MyClass::myFunction() {
//...
}
在這個例子中，myFunction 函式的名稱被修飾為 _ZN7MyClass10myFunctionEv，這樣就可以避免名稱衝突。
在 Rust 中，可以使用 extern "C" 關鍵字來指定 C 連結規範，以避免名稱修飾問題。
// Rust code
extern "C" {
fn my_function();
}
這樣就可以確保 my_function 函式的名稱不會被修飾，從而避免名稱衝突問題。
外部函式介面（FFI）與名稱修飾
在程式設計中，尤其是當我們需要跨語言呼叫函式時，外部函式介面（FFI）是一個非常重要的概念。FFI允許不同的程式語言之間進行通訊和資料交換。然而，在這個過程中，名稱修飾（name mangling）是一個需要注意的問題。
名稱修飾
名稱修飾是指編譯器將函式名稱和其引數型別等資訊編碼成一個唯一的字串，以便於連結器（linker）能夠正確地解析和連結函式。這個過程對於C++語言尤其重要，因為C++支援函式過載（function overloading），即多個函式可以有相同的名稱，但引數列表不同。
以下是一個例子，展示了名稱修飾如何作用：
namespace ns1 {
int32_t add(int32_t a, int32_t b) { return a+b; }
int64_t add(int64_t a, int64_t b) { return a+b; }
}
namespace ns2 {
int32_t add(int32_t a, int32_t b) { return a+b; }
}
在這個例子中，編譯器會將這些函式名稱修飾成唯一的字串，以便於連結器能夠區分它們。使用nm工具可以檢視這些修飾後的名稱：
% nm ffi-cpp-lib.o | grep add
0000000000000000 T __ZN3ns13addEii
0000000000000020 T __ZN3ns13addExx
0000000000000040 T __ZN3ns23addEii
使用c++filt工具可以將這些修飾名稱翻譯回原始的C++函式名稱：
% nm ffi-cpp-lib.o | grep add | c++filt
0000000000000000 T ns1::add(int, int)
0000000000000020 T ns1::add(long long, long long)
0000000000000040 T ns2::add(int, int)
Rust中的外部函式介面
在Rust語言中，外部函式介面是透過extern "C"關鍵字來定義的。這些函式被隱式地標記為`#[no_mangle]”，意味著它們的名稱不會被修飾。這對於與C程式進行互動非常重要，因為C語言不支援名稱修飾。
然而，這也意味著Rust中的外部函式介面缺乏型別安全性。如果函式定義和使用的地方型別不匹配，連結器不會報錯，問題只會在執行時出現。
存取C資料結構
當我們需要在Rust中存取C資料結構時，需要注意資料結構的佈局（layout）。C和Rust可能會以不同的方式將欄位放置在記憶體中。為了避免這種情況，可以使用#[repr(C)]屬性來指定Rust資料結構的佈局與C相容。
以下是一個例子：
typedef struct {
uint8_t byte;
uint32_t integer;
} FfiStruct;
#[repr(C)]
pub struct FfiStruct {
byte: u8,
integer: u32,
}
透過使用#[repr(C)]，我們可以確保Rust中的資料結構與C中的資料結構具有相同的佈局，從而實作兩者之間的正確互動。
控制跨 FFI 界限的內容
在 Rust 中，當我們需要與 C 程式碼進行互動時，我們會使用外部函式介面（FFI）。然而，跨 FFI 界限的內容控制是非常重要的，因為它直接影響著我們程式的安全性和正確性。
字串處理
首先，讓我們來看看字串的處理。在 Rust 中，字串是以 UTF-8 編碼儲存的，並且可能包含零字元，而 C 中的字串則是以 null 結尾的字元陣列。為了確保兩者之間的相容性，我們可以使用 CString 類別來處理 C 樣式的字串。
use std::ffi::CString;
let c_string = CString::new("Hello, World!").unwrap();
let c_str = c_string.as_ptr();
生命週期管理
在 Rust 中，生命週期管理是非常重要的，因為它直接影響著記憶體的安全性。當我們使用 FFI 時，我們需要確保記憶體的分配和釋放是在同一側進行的。為了達到這個目的，我們可以使用 RAII（Resource Acquisition Is Initialization）模式來管理記憶體。
extern "C" {
fn new_struct(v: u32) -> *mut FfiStruct;
fn free_struct(s: *mut FfiStruct);
}
struct FfiWrapper {
inner: *mut FfiStruct,
}
impl Drop for FfiWrapper {
fn drop(&mut self) {
unsafe { free_struct(self.inner) }
}
}
錯誤處理
最後，錯誤處理也是非常重要的。在使用 FFI 時，我們需要確保錯誤是正確地被處理。為了達到這個目的，我們可以使用 Result 類別來處理錯誤。
type Error = String;
impl FfiWrapper {
pub fn new(val: u32) -> Result<Self, Error> {
let p: *mut FfiStruct = unsafe { new_struct(val) };
if p.is_null() {
Err("Failed to get inner struct!".into())
} else {
Ok(Self { inner: p })
}
}
}
內容解密：
CString類別：用於處理 C 樣式的字串。- RAII 模式：用於管理記憶體的分配和釋放。
Result類別：用於處理錯誤。
圖表翻譯：
flowchart TD
A[開始] --> B[分配記憶體]
B --> C[初始化 RAII 封裝]
C --> D[使用 FFI 函式]
D --> E[釋放記憶體]
E --> F[結束]
這個流程圖展示瞭如何使用 RAII 模式來管理記憶體，並且如何使用 FFI 函式來進行跨界限的操作。
Rust 與 C 之間的外部函式介面（FFI）
當我們處理 Rust 和 C 之間的互動時，需要注意許多細節，以確保程式碼的安全性和正確性。以下是幾個重要的原則和範例，展示如何在 Rust 中使用外部函式介面（FFI）與 C 進行互動。
封裝不安全的 FFI 程式碼
一個好的做法是封裝對不安全的 FFI 函式庫的存取在安全的 Rust 程式碼中。這樣做可以讓應用程式的大部分程式碼遵循安全的 Rust 規則，同時集中所有危險的程式碼在一個地方，以便仔細審查和測試。
impl AsMut<FfiStruct> for FfiWrapper {
fn as_mut(&mut self) -> &mut FfiStruct {
// Safety: `inner` is non-NULL.
unsafe { &mut *self.inner }
}
}
let mut wrapper = FfiWrapper::new(42).expect("real code would check");
// 直接修改 C 分配的資料結構內容。
wrapper.as_mut().byte = 12;
從 C 呼叫 Rust 函式
當你從 C 程式碼呼叫 Rust 函式時，需要注意幾點：
extern "C": Rust 函式需要被標記為extern "C"以確保它們的名稱和呼叫規範與 C 相容。#[no_mangle]: 由於 Rust 會對符號名稱進行混淆處理，為了避免這個問題，你需要使用#[no_mangle]屬性來確保函式名稱保持簡單易懂。#[repr(C)]: 資料結構定義需要被標記為#[repr(C)]以確保其內容佈局與 C 中的等效資料結構相容。
#[no_mangle]
pub extern "C" fn add_contents(p: *const FfiStruct) -> u32 {
// 將 C 提供的 raw pointer 轉換為 Rust 參考。
let s: &FfiStruct = unsafe { &*p }; // 注意：這裡可能會發生問題。
s.integer + s.byte as u32
}
處理指標和生命週期
在使用指標和生命週期時，需要特別小心，因為 C 指標和 Rust 參考之間存在差異。
#[no_mangle]
pub extern "C" fn add_contents_safer(p: *const FfiStruct) -> u32 {
let s = match unsafe { p.as_ref() } {
Some(r) => r,
None => return 0, // C 程式碼傳遞了 NULL。
};
s.integer + s.byte as u32
}
控制跨 FFI 界限的內容
在使用 Rust 的外部函式介面（FFI）時，控制跨界限的內容至關重要。這涉及到確保 Rust 和 C 之間的記憶體分配和釋放是一致的，避免因為記憶體管理不當而導致的錯誤。
記憶體分配和釋放
當從 Rust呼叫 C 函式時，需要確保記憶體分配和釋放的一致性。以下是一個例子：
pub extern "C" fn new_struct(v: u32) -> *mut FfiStruct {
let mut s = FfiStruct::new(v);
&mut s // 傳回一個指向堆積疊物件的 raw pointer
}
這個例子中，new_struct 函式傳回一個指向堆積疊物件的 raw pointer。但是，這個指標在函式傳回後就會失效，因為堆積疊物件會被釋放。
為瞭解決這個問題，可以使用 Box::into_raw 函式將堆積疊物件轉換為 raw pointer：
pub extern "C" fn new_struct_raw(v: u32) -> *mut FfiStruct {
let s = FfiStruct::new(v);
let b = Box::new(s);
Box::into_raw(b)
}
這樣可以確保傳回的指標是有效的，並且不會因為堆積疊物件的釋放而失效。
釋放記憶體
但是，如何釋放記憶體呢？可以使用 Box::from_raw 函式將 raw pointer 轉換回 Box，然後讓 Box 自動釋放記憶體：
pub extern "C" fn free_struct_raw(p: *mut FfiStruct) {
if p.is_null() {
return;
}
let _b = unsafe {
Box::from_raw(p)
};
} // `_b` 會在作用域結束時自動釋放記憶體
這樣可以確保記憶體被正確釋放。
關於 FFI 的其他注意事項
- 使用 C 作為最小公分母，所有符號都存在於單一全網域名稱空間中。
- 將不安全的 FFI 程式碼封裝在安全的包裝器中。
- 一致地在界限的一側或另一側進行記憶體分配和釋放。
- 使用 C相容的佈局來定義資料結構。
- 使用定大小的整數型別。
- 使用標準函式庫中的 FFI 相關助手。
- 防止 panic! 從 Rust 逸出。
從底層實作到高階應用的全面檢視顯示，Rust 的外部函式介面（FFI）提供了一個與其他語言，尤其是 C，進行互動操作的有效途徑。然而，跨越 FFI 界限時，Rust 的安全保證機制失效，需要謹慎處理資料型別、函式簽名以及記憶體管理等議題。分析 C 與 Rust 之間的字串處理、生命週期管理和錯誤處理的差異，可以發現，使用 CString、RAII 模式和 Result 類別等工具能有效降低風險。更進一步，#[no_mangle]、#[repr(C)] 等屬性則確保了與 C 程式碼的相容性，而妥善運用 Box::into_raw 和 Box::from_raw 則能有效管理跨語言的記憶體分配與釋放，避免懸空指標等問題。展望未來，隨著 Rust 在更多領域的應用，FFI 的重要性將日益凸顯。開發者應持續關注最佳實務，並積極探索更安全的跨語言互動方案，以充分發揮 Rust 的效能優勢，同時兼顧系統的安全性與穩定性。玄貓認為，深入理解 FFI 機制並嚴格遵循安全規範，是 Rust 開發者建構穩健跨語言應用的關鍵。
