Los peligros: UB, y por qué Vec se construye sobre punteros crudos

Llegamos al filo. Todo lo anterior —crear, dereferenciar, la aritmética, NonNull— entrega poder; esta lección cobra la factura. Los punteros crudos son la vía por la que el comportamiento indefinido, el temido UB, entra en un programa Rust, y hay que entenderlo con exactitud porque casi todo el mundo lo malinterpreta. UB no es “un fallo que crashea”: es una promesa que rompes y sobre la que el compilador ya había construido. Cuando dereferencias un puntero colgante, cuando dejas que dos &mut se solapen, cuando lees un bool que no es ni 0 ni 1, no estás provocando un error definido: estás invalidando una suposición que el optimizador dio por cierta, y a partir de ahí el programa puede hacer literalmente cualquier cosa. Y sin embargo —esta es la paradoja que corona el nivel— es precisamente sobre estos punteros peligrosos, encapsulados con disciplina, sobre lo que Vec, las listas, Rc y toda estructura de datos seria de Rust están construidas.

El catálogo del comportamiento indefinido

El UB con punteros no es un monstruo único sino una familia. Conviene conocer sus caras porque cada estructura de datos que escribas tendrá que esquivarlas todas a la vez.

fn colgante() -> *const i32 {
    let local = 7;
    &raw const local     // apunta a la pila que muere al retornar
}                         // dereferenciar el resultado luego = use-after-free

let mut n = 1_i32;
let p = &raw mut n;
unsafe {
    let a = &mut *p;
    let b = &mut *p;     // dos referencias mutables al mismo sitio: UB aqui mismo
    *a += 1;
    *b += 1;             // el compilador asume que a y b no se solapan
}

Ninguno de estos ejemplos tiene por qué crashear al ejecutarlo. Ese es exactamente el problema.

UB no es un crash: es una licencia

La idea que hay que interiorizar, y que separa a quien escribe unsafe con criterio de quien juega a la ruleta rusa, es esta: el comportamiento indefinido no está definido que falle. El compilador de Rust, vía LLVM, optimiza asumiendo que el UB nunca ocurre. Cuando declaras una &mut, LLVM la marca noalias y reordena, cachea y elide accesos confiando en que nadie más toca esa memoria. Si tú rompes esa promesa con un puntero crudo que aliasea, no obtienes un error ordenado: obtienes un programa cuyo comportamiento el compilador dedujo bajo una premisa falsa. Puede funcionar hoy, fallar mañana al cambiar de versión, o —lo peor— producir resultados sutilmente equivocados sin síntoma alguno.

Por eso cada dereferencia debe respetar, sin excepción, el contrato completo: no nulo, alineado, dentro de una asignación viva, apuntando a un valor inicializado y válido del tipo, y con el aliasing en regla. La red de seguridad se llama Miri: un intérprete del Rust intermedio que ejecuta tu código vigilando el modelo de memoria —Stacked Borrows o Tree Borrows, alineación, inicialización, límites— y aborta con un diagnóstico preciso en cuanto detecta UB, incluso el que no se manifiesta en hardware real. Ejecutar cargo +nightly miri test sobre el código unsafe es una disciplina, no un lujo. Las debug_assertions y los sanitizers complementan la vigilancia en tiempo de ejecución.

La superestructura insegura con fachada segura

Y ahora la vuelta de tuerca que da sentido a todo el nivel. Si los punteros crudos son tan peligrosos, ¿por qué el corazón de la biblioteca estándar está hecho de ellos? Porque la seguridad en Rust no es una propiedad de cada instrucción, sino de la frontera de un módulo. Un Vec es, por dentro, un puntero crudo NonNull<T>, una longitud y una capacidad, más operaciones unsafe de reserva, copia y liberación. Pero ese núcleo peligroso está encapsulado: el módulo mantiene en privado un puñado de invariantes —la capacidad reservada, los primeros len elementos inicializados, el puntero válido— y expone una API pública que ninguna entrada puede usar para provocar UB. Eso es lo que significa que un tipo sea sound: su interfaz segura es imposible de romper desde fuera.

use std::alloc::{alloc, Layout};
use std::ptr::NonNull;

pub struct Pila<T> {
    datos: NonNull<T>,   // nunca nulo; dangling cuando cap == 0
    len: usize,          // invariante: los primeros len elementos estan vivos
    cap: usize,          // invariante: hay sitio reservado para cap elementos
}

impl<T> Pila<T> {
    pub fn nueva() -> Self {
        Pila { datos: NonNull::dangling(), len: 0, cap: 0 }
    }

    pub fn push(&mut self, v: T) {     // firma segura: nadie de fuera ve el unsafe
        if self.len == self.cap {
            self.crecer();             // reserva o duplica capacidad (unsafe dentro)
        }
        unsafe { self.datos.as_ptr().add(self.len).write(v); }
        self.len += 1;                 // se restablece la invariante antes de volver
    }

    // crecer(), pop(), Drop y Deref a &[T] van aqui, cada uno
    // guardando las invariantes tras su propio bloque unsafe.
}

Fíjate en el reparto: push toca punteros crudos y unsafe por dentro, pero su firma es tan segura como cualquier otra, y el usuario del Vec jamás escribe unsafe para llenarlo. El peligro no se elimina —es irreductible en el nivel más bajo—; se concentra en un módulo pequeño, auditable y protegido por invariantes, para que el resto del programa se construya sobre una fachada demostrablemente segura. Toda estructura de datos de Rust —Vec, VecDeque, HashMap, LinkedList, Rc, Box— es una variación de este mismo patrón.

flowchart TD
A[Nucleo unsafe punteros crudos alloc y dealloc] --> B[Modulo que mantiene invariantes en privado]
B --> C[API publica segura que ninguna entrada puede romper]
C --> D[El resto del programa se construye sobre codigo seguro]
M[Miri vigila el nucleo en las pruebas] --> A
style A fill:#f38ba8,color:#11111b
style B fill:#f9e2af,color:#11111b
style C fill:#a6e3a1,color:#11111b
style D fill:#89b4fa,color:#11111b
style M fill:#cba6f7,color:#11111b