Modul 21 — Foreign Functions: Rust & C zusammenbringen (FFI)

Rust & C: Maschinensprache verbindet

FFI (Foreign Function Interface) erlaubt es Rust, Funktionen aus anderen Sprachen aufzurufen — meist C/C++. Der gemeinsame Nenner von Rust und C ist Maschinensprache: Wenn du wissen willst, wie Rust-Werte für C aussehen (und umgekehrt), musst du ihre Darstellung im Speicher betrachten.

Die gute Nachricht: Rust und C teilen viele Repräsentationen:

• ein Rust usize und ein C size_t sind identisch
• Structs sind in beiden Sprachen grundlegend dieselbe Idee

Wozu FFI?

• Bestand bestehender Bibliotheken: SQLite, libgit2, OpenSSL
• System-C-APIs: libc-Funktionen wie strlen, malloc
• Performance oder Legacy-Code, der sich nicht neu schreiben lässt

Die std::ffi-Typen

std::ffi definiert Rust-Typen, die garantiert dieselbe Darstellung wie C-Typen haben. Das schützt dich vor plattformabhängigen C-Größen:

Warum nicht direkt i32?

Ein C int ist nicht überall garantiert 32 Bit. c_int ist immer das, was C int auf dieser Plattform ist. Damit bleibt dein FFI-Code portabel — und sagt klar, dass du mit C-Code sprichst.

Eine C-Funktion anmelden

Ein extern-Block deklariert Funktionen oder Variablen, die in einer anderen Bibliothek definiert sind und mit dem finalen Rust-Programm gelinkt werden. So sagst du Rust, wie C's strlen aussieht:

use std::ffi::c_char;

unsafe extern "C" {
    fn strlen(s: *const c_char) -> usize;
    // ^ C-Konventionen, ^ unsafe, weil sie einen Vertrag hat
}

• extern "C" = es gelten C-Aufrufkonventionen
• Die Funktion ist unsafe: sie verlangt z. B. einen validen, null-terminierten String — ein Vertrag, den Rust nicht erzwingen kann.

In Rust aufrufen

use std::ffi::{c_char, CString};

fn main() {
    let rust_str = "I'll be back";
    let null_terminated = CString::new(rust_str).unwrap();

    unsafe {
        assert_eq!(strlen(null_terminated.as_ptr()), 12);
    }
}

CString::new baut einen null-terminierten C-String. Es prüft auf eingebettete Null-Bytes (die in C-Strings unmöglich sind) und fügt das abschließende Null-Byte hinzu. Deshalb das unwrap.

Übung: C-Funktion aufrufen

Eine externe Bibliothek anbinden

Stehen die Funktionen nicht in der Standard-C-Lib, sondern in einer bestimmten Bibliothek, nennst du sie mit #[link] an der Spitze des extern-Blocks. Beispiel libgit2:

use std::ffi::c_int;

#[link(name = "git2")]
unsafe extern "C" {
    pub fn git_libgit2_init() -> c_int;
    pub fn git_libgit2_shutdown() -> c_int;
}

fn main() {
    unsafe {
        git_libgit2_init();
        git_libgit2_shutdown();
    }
}

#[link(name = "git2")] sagt dem Linker: Binde gegen libgit2. Das Verhalten hängt davon ab, wie libgit2 auf deinem System installiert ist.

Das Muster: roh ist innerlich, sicher von außen

Rohe FFI-Calls sind unsafe und mühsam. Die Kunst liegt darin, sie in einem sicheren Interface einzukapseln: Das Innere ist unsafe, die öffentliche API ist safe und bietet einen Vertrag.

struct Rechner;

impl Rechner {
    // SAFETY: libc::strlen ist gültig, weil wir null-terminiert übergeben.
    fn textlaenge(text: &str) -> usize {
        let c = std::ffi::CString::new(text).expect("kein \\0 erlaubt");
        unsafe { strlen(c.as_ptr()) }
    }
}

Von außen ruft man Rechner::textlaenge("hallo") — sicher, ohne unsafe, und mit garantierter korrekter Nutzung.

Der Vertrag von Hüll-Funktionen

Eine sichere Hüll-Funktion muss:

1. Kontrakt sicherstellen: gültige, null-terminierte Strings; gültige Zeiger
2. unsafe auf das Innere beschränken und jedes Vorkommen mit // SAFETY: begründen
3. C-Fehler abfangen: git_libgit2_init() liefert einen c_int-Status — deine Hülle wandelt ihn in ein Result oder panic! um
4. Sauber deinitialisieren: Drop verwendet, um z. B. git_libgit2_shutdown() automatisch zu rufen

Übung: Sichere Hülle für abs

Real-Welt-FFI

Viele populäre Rust-Crates sind dünne sichere Hüllen um C-Bibliotheken:

• git2 — sichere Hülle um libgit2 (Git in Rust)
• openssl / ring — kryptografie-APIs (OpenSSL / C)
• rusqlite — sichere Hülle um SQLite
• libc — direkter Zugriff auf die C-Standardbibliothek

Diese Crates funktionieren nach dem Muster von Lektion 5: innen unsafe FFI, außen eine sichere, idiomatische Rust-API.

Das Gesamtbild: raw → safe Schichten

            ┌────────────────────────────────────────┐
            │  Rust-Anwendung (sicher, idiomatisch)  │
            ├────────────────────────────────────────┤
            │  git2 / rusqlite (sichere Hülle)       │
            ├────────────────────────────────────────┤
            │  extern-Blöcke + #[link] (unsafe FFI)  │
            ├────────────────────────────────────────┤
            │  libgit2 / SQLite (C-Bibliothek)       │
            └────────────────────────────────────────┘

Jede Schicht fasst die darunter liegende Unbequemlichkeit ein und bietet nach oben eine bequemere, sicherere Schnittstelle.

Projekt: strlen sicher einkapseln

Du baust eine sichere Rust-API um die C-Funktion strlen — das prüft die FFI-Kernkonzepte dieses Moduls:

1. Deklariere strlen(s: *const c_char) -> usize in einem unsafe extern "C" Block (importiere c_char aus std::ffi).
2. Schreibe eine sichere Funktion textlaenge(text: &str) -> usize, die innen CString::new + unsafe { strlen(...) } verwendet, mit // SAFETY: Kommentar.
3. Teste sie mit einem &str-Argument — ohne dass main selbst unsafe berührt.
4. Überlege: Warum ist die öffentliche API sicher, obwohl innen C-Code läuft?

Das verbindet: extern-Blöcke, std::ffi-Typen, CString, Unsafe-Argumentation und das sichere-Hülle-Muster von Lektion 5.

Übung: strlen mit sicherer Hülle