Cuándo usar unsafe, cuándo no, y Miri

Llegamos al juicio práctico: ¿cuándo se justifica unsafe y cuándo es una señal de rendición? Hay motivos legítimos y son pocos y reconocibles: interoperar con C u otro lenguaje (FFI), construir estructuras de datos que el borrow checker genuinamente no sabe expresar —listas intrusivas, grafos, arenas, tipos autorreferenciales—, y aplicar optimizaciones que has medido y demostrado necesarias. Y hay un motivo ilegítimo que causa la mayoría del unsafe malo del mundo: usarlo para callar un error del compilador que no entendiste, o para un rendimiento que jamás cronometraste. La disciplina que separa a un ingeniero de sistemas de un accidente andante es la parsimonia: gastar unsafe como moneda escasa —lo mínimo, lo más encapsulado, lo más documentado y lo más probado posible—. Y para lo último existe una herramienta casi mágica: Miri, un intérprete que ejecuta tu código bajo un microscopio y detecta el comportamiento indefinido que ningún compilador de producción ve.

Cuándo sí, y cuándo no

La decisión se resuelve casi siempre con una tabla mental honesta:

La asimetría importa: los tres “sí” comparten que la alternativa segura no existe o está medidamente fuera de presupuesto; el “no” siempre esconde una alternativa segura que el autor no quiso encontrar. Antes de escribir unsafe, la pregunta obligatoria es: “¿puedo expresar esto de forma segura?”. Si la respuesta honesta es sí, no hay unsafe que valga.

Un ejemplo del uso ilegítimo, tan común que conviene reconocerlo de un vistazo:

// MAL: unsafe para callar un error que no se entendio.
fn mal(v: &mut Vec<i32>) {
    let a = &mut v[0];
    let b = unsafe { &mut *(a as *mut i32) }; // dos &mut al mismo i32
    *a += 1;
    *b += 1;                                   // UB latente por aliasing
}

Aquí unsafe no resolvió nada: fabricó dos referencias mutables al mismo entero saltándose el puntero crudo, que es precisamente la invariante que jamás debe romperse. Compila, pero es comportamiento indefinido. La señal de alarma es que el unsafe aparece para ganar un aliasing, no para interoperar ni para una estructura que el lenguaje no exprese: casi siempre que unsafe es la respuesta a “el borrow checker no me deja”, la pregunta estaba mal planteada.

La disciplina: minimizar y encapsular

Cuando unsafe está justificado, el oficio es reducir su coste para el lector y el revisor, porque cada bloque unsafe es un lugar donde la garantía del compilador se interrumpe y un humano debe rederivarla. Dos reglas gobiernan:

Primero, bloques diminutos: encierra en unsafe solo la operación que de verdad lo exige, para que el compilador siga verificando todo lo demás. Segundo, encapsulación sólida: envuelve el unsafe tras una API segura cuya solidez hayas probado, de modo que el resto del programa herede la seguridad sin volver a tocar la palabra.

pub struct ParImpar<'a> {
    pares: &'a mut [i32],
    impares: &'a mut [i32],
}

pub fn separar(v: &mut [i32]) -> (&mut [i32], &mut [i32]) {
    let mid = v.len() / 2;
    // API publica SEGURA: quien la llama nunca escribe unsafe.
    v.split_at_mut(mid)   // el unsafe vive encapsulado dentro de split_at_mut
}

El usuario de separar obtiene dos slices mutables disjuntos sin escribir ni ver unsafe: la superficie peligrosa quedó sellada dentro de std. Ese es el patrón de todo Rust idiomático de bajo nivel: un núcleo unsafe minúsculo y auditado, una frontera segura y sólida, y encima un océano de código que hereda las garantías gratis.

Ese patrón tiene nombre en la comunidad: encapsulación de la inseguridad. La medida de calidad de una crate de bajo nivel no es cuánto unsafe contiene, sino cuánto unsafe logra no filtrar a sus usuarios. Una biblioteca excelente puede tener miles de líneas unsafe por dentro y una API pública en la que ningún usuario teclea jamás la palabra. La superficie que de verdad importa auditar no es la interna, sino la que queda expuesta: idealmente, ninguna.

Miri: la conciencia que ejecuta tu unsafe

Ningún compilador de producción detecta el UB: lo asume ausente y optimiza. Miri hace lo contrario. Es un intérprete de nivel MIR que ejecuta tu programa en una máquina virtual instrumentada y detecta en el acto el comportamiento indefinido: accesos fuera de rango, uso tras liberación, lecturas de memoria sin inicializar, desalineación, valores inválidos, carreras de datos y violaciones de aliasing bajo su modelo operativo (Stacked Borrows / Tree Borrows).

rustup +nightly component add miri
cargo +nightly miri test
cargo +nightly miri run

Considera este UB clásico —un puntero que sobrevive a su dato— que compila, e incluso “parece funcionar” en release, pero es una bomba:

fn main() {
    let p;
    {
        let v = vec![1, 2, 3];
        p = v.as_ptr();      // p apunta al buffer de v
    }                         // v se destruye aqui: p queda colgante
    let _leido = unsafe { *p }; // uso tras liberacion: UB
    println!("{_leido}");
}

Un cargo run normal podría imprimir un número plausible y engañarte. Miri, en cambio, detiene la ejecución y señala el uso tras liberación con la línea exacta. No es una prueba de corrección total —solo inspecciona las rutas que tus tests recorren, no todas las posibles—, pero atrapa la inmensa mayoría de los errores reales de unsafe. La receta profesional combina tres capas: pruebas que ejerciten los caminos, Miri sobre esas pruebas, y fuzzing para generar entradas que a ti no se te ocurrirían.

Conviene ser honesto sobre los límites de Miri. No demuestra la ausencia de UB —solo inspecciona lo que se ejecuta, así que una rama nunca cubierta queda a oscuras—; no mide rendimiento, porque interpreta y es mucho más lento que el binario real; y su modelo de aliasing sigue siendo experimental, de modo que en casos raros puede marcar como sospechoso un patrón que la comunidad aún debate. Nada de eso le resta valor: sigue siendo, con diferencia, la mejor red que existe para el unsafe. Pero es una red, no una demostración, y conviene usarla sabiéndolo.

Visto en conjunto, el flujo de trabajo del unsafe responsable encadena cuatro exigencias que se refuerzan entre sí: justificar, minimizar, encapsular y auditar. Ninguna sustituye a las demás, y saltarse una deja un hueco por el que el UB se cuela. Justificar sin encapsular filtra el peligro; encapsular sin auditar confía a ciegas; auditar sin minimizar obliga a Miri a razonar sobre más superficie de la necesaria.

flowchart LR
J[Existe alternativa segura] -->|no o medidamente lento| M[Minimizar el bloque unsafe]
J -->|si existe| S[No usar unsafe]
M --> E[Encapsular tras una API solida]
E --> A[Auditar con Miri sobre las pruebas]
A --> F[unsafe defendible]
style J fill:#cba6f7,color:#11111b
style E fill:#89b4fa,color:#11111b
style A fill:#f38ba8,color:#11111b
style F fill:#a6e3a1,color:#11111b
style S fill:#a6e3a1,color:#11111b