Tipos compatibles con C: repr(C), los escalares de core::ffi y las cadenas

Cuando declaras que una función de C recibe un struct, estás prometiendo algo mucho más fuerte que “un tipo con estos campos”: prometes que los bytes están dispuestos exactamente donde C los espera. Y aquí surge un conflicto silencioso. El repr(Rust) por defecto se reserva el derecho de reordenar los campos, insertar relleno donde le convenga y empaquetar dos tipos distintos de forma distinta entre versiones del compilador. Esa libertad es la que le permite optimizar el tamaño y la alineación, pero convierte cualquier struct de Rust en un layout impredecible desde fuera. Para hablar con C hay que renunciar a esa libertad con #[repr(C)], que congela la disposición a las reglas de C. Y no solo los agregados: cada escalar debe ser el que C entiende —c_int, no i32— y las cadenas, que en los dos lenguajes son cosas radicalmente distintas, hay que traducirlas a mano.

repr(C): un layout que C puede predecir

Por defecto Rust usa repr(Rust): el orden de los campos en memoria no tiene por qué ser el de la declaración, y el compilador puede reordenarlos para minimizar el relleno. #[repr(C)] desactiva esa libertad y aplica las reglas de C: campos en orden de declaración, con la alineación y el relleno que usaría un compilador de C en esa plataforma.

use core::ffi::c_int;

#[repr(C)]
struct Punto {
    x: c_int,
    y: c_int,
}

unsafe extern "C" {
    fn distancia_origen(p: Punto) -> f64;
}

Ahora Punto tiene un layout que C reconoce byte a byte, y puede pasarse por valor o por puntero a través de la frontera. Los enum también admiten repr: #[repr(C)] o #[repr(i32)] sobre un enum sin datos fija el tipo entero del discriminante, imprescindible para que C lo lea como el enum que es.

Los escalares de core::ffi

La segunda promesa es sobre el ancho de los escalares. En C, int no siempre son 32 bits y char puede ser con o sin signo según la plataforma. Escribir i32 a ciegas es correcto en tu máquina y una bomba en otra. Los alias de core::ffi resuelven esto: cada uno equivale al tipo de C correspondiente en la plataforma de destino.

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

unsafe extern "C" {
    fn procesar(datos: *mut c_void, longitud: c_uint) -> c_int;
    fn nombre_byte(indice: c_int) -> c_char;
}

• c_int, c_uint, c_long, c_double: los escalares numéricos, con el ancho de C.
• c_char: es i8 o u8 según la plataforma; por eso existe el alias en vez de fijar uno.
• c_void: el tipo opaco tras un puntero (*mut c_void), el equivalente de void* de C.

Desde Rust 1.64 estos alias viven en core::ffi —disponibles incluso sin std— y se re-exportan en std::ffi y en el antiguo std::os::raw. Usarlos no es solo corrección: documenta la intención, porque un c_int en una firma grita “esto habla con C”.

Cadenas: el terminador nulo frente a la longitud

Aquí el choque es de modelos de memoria. Un str de Rust es un puntero más una longitud, codificado en UTF-8, y no termina en nulo. Una cadena de C es un puntero a char que termina en un byte nulo y no lleva longitud: hay que recorrerla hasta el \0 para saber dónde acaba. Dos tipos tienden el puente:

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

// Rust -> C: CString posee una cadena en el heap, con nulo final garantizado.
fn hacia_c(s: &str) -> CString {
    CString::new(s).expect("no debe haber un nulo interior")
}

// C -> Rust: CStr toma prestada una cadena terminada en nulo que ya existe.
unsafe fn desde_c(p: *const c_char) -> String {
    let cstr = unsafe { CStr::from_ptr(p) };  // recorre hasta el nulo
    cstr.to_string_lossy().into_owned()
}

CString es a CStr lo que String a str: el primero posee y asigna en el heap; el segundo es una vista prestada. CString::new falla si la cadena contiene un nulo interior, porque eso rompería la invariante de C. Y desde Rust 1.77 existen los literales c"...", que producen un &CStr con el nulo puesto en tiempo de compilación:

use core::ffi::CStr;
let saludo: &CStr = c"hola";   // terminado en nulo, sin asignacion en runtime

flowchart TB
subgraph Rust
  A[str y String son puntero mas longitud en UTF-8 sin nulo final]
end
subgraph C
  B[char asterisco es un puntero terminado en byte nulo sin longitud]
end
A -->|CString new asigna y anade el nulo| B
B -->|CStr from_ptr recorre hasta el nulo| A
style A fill:#89b4fa,color:#11111b
style B fill:#fab387,color:#11111b

repr(transparent): el newtype que no cuesta ABI

Hay un repr más al servicio de la FFI, y resuelve un problema muy concreto: envolver un tipo en un struct de un solo campo para ganar seguridad en Rust sin alterar el layout que ve C. #[repr(transparent)] garantiza que el struct tiene exactamente la misma representación que su único campo no vacío.

use core::ffi::c_int;

#[repr(transparent)]
struct Descriptor(c_int);   // identico a c_int para C, distinto para Rust

unsafe extern "C" {
    fn cerrar(fd: Descriptor) -> c_int;
}

Para C, Descriptor es un c_int; para Rust, es un tipo aparte que no puedes confundir con cualquier otro entero. Ganas el patrón newtype —imposible pasar un entero cualquiera donde se espera un descriptor— al precio de cero bytes y cero indirección. Es la manera idiomática de dar nombres con tipo a los enteros crudos que pululan por las APIs de C.