Invariantes y la responsabilidad del bloque unsafe

Cuando abres un bloque unsafe, el compilador deja de comprobar un puñado de invariantes, pero esas invariantes no dejan de existir: solo cambian de guardián. Pasas a ser tú quien garantiza que cada puntero apunta a memoria válida y alineada, que ninguna referencia mutable comparte su objeto con otra, que ningún valor lleva bits que su tipo prohíbe. Y si fallas, no obtienes una excepción ni un panic diagnosticable: obtienes comportamiento indefinido —Undefined Behavior, UB—, la única categoría de fallo que toda la arquitectura de Rust existe para abolir. El UB no es “quizá peta”: es peor, porque el optimizador razona desde la premisa de que jamás ocurre y compila tu programa a partir de esa mentira. Un solo unsafe incorrecto en un millón de líneas puede envenenar el binario entero. Por eso el oficio del unsafe gira en torno a un hábito aparentemente burocrático y en realidad central: nombrar, en cada punto, la invariante que estás sosteniendo.

Qué invariantes pasan a tu cargo

El compilador deja de vigilar, entre otras, estas condiciones —y ahora las firmas tú:

Ninguna de estas condiciones es nueva: son las mismas que el borrow checker, el sistema de tipos y el inicializador imponían por ti fuera de unsafe. Lo que cambia no es la regla, sino quién responde de ella.

Conviene además separar dos niveles de invariante que la tradición de Rust distingue con cuidado. La invariante de validez debe cumplirse en todo instante o hay UB inmediato: un &T no puede ser nulo, ni estar desalineado, ni un microsegundo. La invariante de seguridad es más laxa: puedes romperla temporalmente dentro de un bloque unsafe mientras reconstruyes una estructura, con tal de restaurarla antes de devolver el control a código seguro. Un Vec a medio redimensionar viola su invariante de seguridad por un instante, jamás la de validez. Saber en cuál de los dos niveles operas te dice cuánto margen tienes antes de cruzar la línea sin retorno.

Estas invariantes comparten un rasgo incómodo: en su mayoría son no locales. Que un puntero sea válido depende de que su asignación siga viva, lo cual depende de código que quizá está en otra función. Que un &mut sea único depende de que nadie más, en ningún punto alcanzable del programa, sostenga otra referencia al mismo dato. Verificarlas a mano exige razonar sobre el programa entero, no sobre la línea que tienes delante, y ahí reside la verdadera dificultad del unsafe: no en teclear la palabra, sino en cargar con una obligación cuyo alcance excede el bloque.

Comportamiento indefinido: la premisa, no el síntoma

El error fatal es pensar el UB como “un fallo que puede o no manifestarse”. El UB es una premisa lógica que el compilador toma como axioma. La especificación dice: “estas cosas nunca ocurren”; el optimizador lo cree literalmente y transforma tu código apoyándose en esa certeza. Si tú provocas una de esas cosas, no has causado “un fallo”: has hecho falsa una premisa sobre la que se construyó todo el razonamiento, y de una premisa falsa se deduce cualquier cosa.

let x: u8 = 3;
let b: bool = unsafe { std::mem::transmute(x) }; // UB: 3 no es un bool valido
if b { /* ... */ } else { /* ... */ }            // el compilador puede tomar
                                                  // cualquier rama, o ninguna

Aquí b contiene el patrón de bits 3, que ningún bool legítimo tiene. El compilador, que sabe por especificación que todo bool vale 0 o 1, puede haber generado código que asume exactamente eso: podría saltar a una rama imposible, indexar una tabla fuera de rango, o borrar el if entero. No hay “resultado incorrecto pero acotado”; hay ausencia total de significado. Esa es la diferencia abismal entre un panic —parada definida y diagnosticable— y el UB —terreno sin mapa.

Por eso los lenguajes que admiten UB ponen tanto peso en no cometerlo jamás: no existe un manejo posterior, no hay catch, no hay recuperación. La única defensa es la prevención, y la prevención vive en las invariantes que ahora sostienes. Un Result te deja reaccionar a un fallo; un UB no te deja reaccionar a nada, porque para cuando se manifiesta, el significado del programa ya se evaporó y el binario que ejecutas puede no corresponder a ninguna lectura sensata de tu código fuente.

Un segundo ejemplo, más cotidiano que el transmute, es la referencia colgante fabricada con punteros crudos:

fn colgante() -> i32 {
    let p: *const i32;
    {
        let x = 10;
        p = &x;         // p apunta a x
    }                    // x muere aqui: p queda colgante
    unsafe { *p }        // UB: leer memoria de un valor que ya no existe
}

El borrow checker habría rechazado este patrón con referencias normales; al bajar a un puntero crudo lo permitiste, y con ello asumiste la invariante de validez que el compilador sostenía. Leer *p tras la muerte de x no “a veces da basura”: es UB, y el optimizador puede compilar colgante de maneras que ni siquiera devuelven un entero coherente.

Solidez: el criterio que decide si tu unsafe es correcto

La pregunta correcta ante una abstracción con unsafe no es “¿mi ejemplo funciona?”, sino “¿existe alguna entrada segura que provoque UB?”. Si existe una sola, aunque tú nunca la uses, la abstracción es no sólida (unsound) y está rota. Mira el papel de un assert:

pub struct Bolsa {
    ptr: *mut u8,
    len: usize,
}

impl Bolsa {
    pub fn obtener(&self, i: usize) -> u8 {
        assert!(i < self.len);              // este assert es lo que la hace SOLIDA
        // SAFETY: i < len garantiza que ptr.add(i) cae dentro del bloque vivo.
        unsafe { *self.ptr.add(i) }
    }
}

El assert parece un peaje molesto, pero es la pieza que sostiene la solidez. obtener es una función segura: cualquiera puede llamarla con cualquier i sin escribir unsafe. Si borras el assert, entonces bolsa.obtener(9999) —una llamada perfectamente segura desde la perspectiva del que la usa— desreferencia un puntero fuera de rango y comete UB. La abstracción se vuelve no sólida no porque tú la uses mal, sino porque permite usarla mal desde código seguro. El comentario // SAFETY: documenta la invariante exacta que el bloque presupone; el assert la hace cierta.

Procedencia: el puntero recuerda de dónde viene

Hay una invariante aún más sutil que gobierna los punteros crudos: la procedencia (provenance). En el modelo abstracto de Rust un puntero no es un mero número: lleva asociado el permiso de acceder a una asignación concreta. Dos punteros con idéntica dirección numérica pueden tener procedencias distintas, y usar uno para tocar la memoria del otro es UB aunque el entero coincida. Por eso pasear un puntero fuera de su asignación con aritmética y luego desreferenciarlo es indefinido, por más que la dirección resultante “exista” en el mapa de memoria del proceso:

let a = [10u8, 20, 30];
let p = a.as_ptr();
let q = p.wrapping_add(10);   // direccion fuera de la asignacion de `a`
// Desreferenciar q es UB: su procedencia es la de `a`, y ahi no cae dentro.

La edición 2024 consolidó una API de procedencia estricta —.addr(), .with_addr(), ptr::without_provenance— que separa la dirección numérica del permiso de acceso, para escribir código de punteros correcto por construcción en vez de por casualidad. Y por debajo, qué secuencias exactas de accesos son legales lo fijan modelos operativos experimentales: Stacked Borrows y su sucesor Tree Borrows. No hace falta dominarlos para escribir unsafe sólido, pero sí saber que existen, porque son precisamente las reglas que Miri aplicará para cazarte una violación de aliasing que tus ojos no vieron.

flowchart LR
A[Asignacion del array a] --> P[Puntero p con procedencia de a]
P --> V[Derivado dentro de a: desreferenciar es valido]
P --> U[Derivado fuera de a: desreferenciar es UB]
style A fill:#89b4fa,color:#11111b
style V fill:#a6e3a1,color:#11111b
style U fill:#f38ba8,color:#11111b