Llamar a C desde Rust: declarar extern C, enlazar y por qué es unsafe

Rust no vive solo. Debajo de casi cualquier sistema real hay una capa de C: la biblioteca estándar del sistema operativo, libc, los drivers, motores como SQLite o OpenSSL, décadas de código probado que nadie va a reescribir. La interfaz de función foránea —la FFI— es el puente por el que Rust llama a ese mundo. Pero cruzar el puente tiene un precio exacto: al otro lado terminan las garantías. El compilador que demostró que tu programa no tenía use-after-free ni data races no puede ver el cuerpo de una función de C. Solo tiene tu palabra sobre qué firma tiene y qué contrato exige. Por eso la sintaxis para declararla se llama unsafe extern "C" y por eso toda llamada va envuelta en unsafe: es el punto donde la prueba del compilador se detiene y empieza tu responsabilidad.

El bloque extern: declarar sin definir

Un bloque extern no define funciones: declara sus firmas y promete que el símbolo existirá en tiempo de enlazado. La cadena "C" fija la ABI —la convención de llamada— con la que se pasan argumentos y se devuelve el resultado. En la edición 2024 el bloque entero debe marcarse unsafe extern, porque declarar una firma foránea es ya una afirmación que nadie puede comprobar por ti:

use core::ffi::c_int;

unsafe extern "C" {
    fn abs(input: c_int) -> c_int;
}

fn main() {
    let x: c_int = -42;
    let y = unsafe { abs(x) };   // la llamada exige unsafe
    println!("|{x}| = {y}");
}

Aquí no hay cuerpo tras abs: solo la firma. El compilador la toma como un contrato —“existe un símbolo llamado abs que recibe un c_int y devuelve otro”— y deja un hueco que el enlazador rellenará. abs vive en libc, que Rust enlaza automáticamente, así que este ejemplo compila sin más ceremonia.

Por qué unsafe: el contrato que el compilador no ve

La razón de unsafe no es ritual, es literal. El compilador no tiene el cuerpo de abs. No puede verificar que la firma que escribiste coincida con la real, ni que los punteros que pases sean válidos, ni que C no provoque una carrera de datos, ni que respete los lifetimes que Rust presupone. Toda esa carga de prueba, que dentro de Rust lleva el compilador, cruza la frontera y cae sobre ti. Cada llamada a C es un lugar donde le prometes al compilador lo que él no puede demostrar.

La edición 2024 refina esto: dentro del bloque puedes anotar cada declaración como safe o unsafe. Una función safe afirma que llamarla no exige ninguna precondición del llamador; una unsafe traslada esa exigencia a quien la invoca:

use core::ffi::{c_char, c_int};

unsafe extern "C" {
    // Asegurar que la firma es correcta sigue siendo cosa tuya,
    // pero llamarla no exige nada mas: es segura de invocar.
    safe fn abs(input: c_int) -> c_int;

    // El llamador DEBE garantizar que s apunta a bytes validos
    // terminados en un nulo. Por eso invocarla es unsafe.
    unsafe fn strlen(s: *const c_char) -> usize;
}

Enlazar la biblioteca

Declarar la firma no basta: el símbolo tiene que resolverse contra código máquina real. libc se enlaza sola, pero cualquier otra biblioteca hay que nombrarla. La forma directa es el atributo #[link] sobre el bloque:

#[link(name = "m")]   // libm, la biblioteca matematica del sistema
unsafe extern "C" {
    safe fn cbrt(x: f64) -> f64;   // raiz cubica
}

La forma flexible, y la que usan las crates serias, es un build script. El fichero build.rs se ejecuta antes de compilar y emite directivas para Cargo:

// build.rs
fn main() {
    println!("cargo:rustc-link-lib=m");                       // enlaza libm
    println!("cargo:rustc-link-search=native=/usr/local/lib"); // donde buscarla
}

El build script gana cuando la ruta o el nombre de la biblioteca dependen de la plataforma, o cuando primero hay que compilar código C con una crate como cc. El atributo #[link] gana por su brevedad cuando la biblioteca es estándar y siempre está.

flowchart LR
A[Codigo Rust con bloque unsafe extern C] --> B[El compilador emite un objeto con el simbolo sin resolver]
B --> C[El enlazador busca el simbolo]
D[Biblioteca nativa libm o libc] --> C
C --> E[Ejecutable final que llama a C]
style A fill:#89b4fa,color:#11111b
style C fill:#cba6f7,color:#11111b
style D fill:#fab387,color:#11111b
style E fill:#a6e3a1,color:#11111b

Más allá de la ABI C: variádicas y otras convenciones

La cadena "C" es la ABI más común, pero no la única. Rust admite otras convenciones cuando el símbolo foráneo las exige: "system" —que en Windows selecciona stdcall para las APIs del sistema y equivale a "C" en el resto—, o "C-unwind", que permite que un unwinding cruce la frontera de forma controlada en lugar de abortar. Y muchas funciones de C son variádicas, como printf: reciben un número variable de argumentos, declarados con ... tras los parámetros fijos.

use core::ffi::{c_char, c_int};

unsafe extern "C" {
    fn printf(formato: *const c_char, ...) -> c_int;
}

Invocar una variádica es especialmente delicado: el compilador no comprueba que los argumentos casen con la cadena de formato, así que un tipo equivocado es UB inmediato. Es el recordatorio más crudo de que en la FFI la firma es una promesa que solo tú sostienes.