Antes de Rust 1.36, los desarrolladores confiaban en std::mem::uninitialized para asignar memoria en la pila para valores que se inicializarían más tarde. Esta función era fundamentalmente insegura porque le decía al compilador que existía un T válido en esa ubicación de memoria, aunque los bits fueran aleatorios. Para tipos con invariantes de seguridad—como bool, char o referencias—esto conducía a un comportamiento indefinido inmediato, ya que el compilador optimizaba basándose en la suposición de que el valor era válido (por ejemplo, un bool siendo 0 o 1). RFC 1892 introdujo MaybeUninit<T> como una abstracción similar a una unión para denotar explícitamente la memoria que aún no contiene un T válido, resolviendo este agujero de seguridad.
El problema central proviene del tratamiento de la memoria no inicializada por parte de LLVM como undef o poison, junto con la generación automática de drop glue de Rust. Cuando el compilador cree que una variable de tipo T está activa, puede emitir llamadas al destructor u optimizaciones específicas. Si T es un bool, un byte no inicializado podría tener el valor 2, lo que viola la invariante de validez de bits. Leer esto durante la comprobación de eliminación o inspección de discriminadores constituye un comportamiento indefinido. Además, si la inicialización falla durante un recorrido de array, el glue de eliminación para el tipo de array intentaría eliminar todos los elementos, interpretando bytes de pila no inicializados como punteros y causando errores de uso después de liberación o doble liberación.
MaybeUninit<T> actúa como un contenedor tipado que puede o no contener un T válido. Impide que el compilador asuma la inicialización, inhibiendo así la emisión de glue de eliminación y las optimizaciones de patrones de bits no válidos. El programador debe rastrear manualmente qué instancias están inicializadas, generalmente a través de un índice separado o un array booleano. Para extraer un valor, se utiliza assume_init, assume_init_ref o std::ptr::read, pero solo después de escribir de manera comprobable un T válido a través de write o manipulación de punteros. La invariante crítica es que assume_init nunca debe llamarse en memoria que no esté completamente inicializada, y al abandonar una estructura parcialmente inicializada, el programador debe eliminar manualmente solo los elementos inicializados usando ptr::drop_in_place para evitar pérdidas de recursos.
use std::mem::{self, MaybeUninit}; use std::ptr; fn init_array_fallible<T, E, const N: usize>( mut f: impl FnMut(usize) -> Result<T, E>, ) -> Result<[T; N], E> { let mut array: [MaybeUninit<T>; N] = unsafe { MaybeUninit::uninit().assume_init() }; let mut i = 0; while i < N { match f(i) { Ok(val) => { array[i].write(val); i += 1; } Err(e) => { for j in 0..i { unsafe { ptr::drop_in_place(array[j].as_mut_ptr()); } } return Err(e); } } } Ok(unsafe { mem::transmute::<[MaybeUninit<T>; N], [T; N]>(array) }) }
Estás desarrollando un controlador de kernel no_std para una tarjeta de red donde se prohíbe la asignación de memoria en el heap y la latencia debe ser determinista. Necesitas asignar una tabla de tamaño fijo de 1024 objetos Connection en la pila. Cada inicialización de Connection implica una escritura en un registro de hardware que puede fallar si el búfer de NIC está lleno. El desafío es asegurar que si la 500ª conexión falla, las 499 anteriores se cierren correctamente (eliminando descriptores de archivo y liberando asignaciones de DMA) mientras los 524 espacios restantes se dejen intactos, evitando cualquier comportamiento indefinido por eliminar memoria no inicializada.
Un enfoque potencial implica utilizar Default::default() para pre-inicializar el array con valores centinela. Esto requiere que Connection implemente Default, lo cual es problemático porque una conexión "por defecto" aún adquiriría recursos del kernel que deben liberarse explícitamente, complicando el camino de error. Además, construir 1024 conexiones dummy solo para sobrescribirlas desperdicia ciclos de inicialización y viola los estrictos requisitos de temporización del controlador para poner la interfaz online.
Una segunda estrategia emplea Vec<Connection> con with_capacity y un empuje dinámico, seguido de la conversión a un array fijo. Esto es seguro e idiomático en código de espacio de usuario. Sin embargo, Vec requiere un asignador global, que no está disponible en este contexto del kernel. También introduce posibles caminos de pánico y fragmentación de memoria que no son aceptables en el espacio del kernel, y la conversión a un array de tamaño fijo requiere verificaciones en tiempo de ejecución que complican la lógica de manejo de errores.
El tercer enfoque aprovecha MaybeUninit<[Connection; 1024]> para asignar el almacenamiento sin inicialización. Las conexiones inicializadas con éxito se escriben a través de MaybeUninit::write, y si ocurre un error en el índice i, iteramos manualmente desde 0 hasta i-1 y llamamos a ptr::drop_in_place en cada espacio inicializado antes de devolver el error. Al tener éxito, transmutamos todo el array al tipo inicializado. Elegimos esta solución porque proporciona asignación de pila sin costo y rendimiento determinista, satisface la condición no_std, y garantiza que la limpieza de recursos solo ocurra para objetos verdaderamente inicializados. El resultado fue un controlador robusto que nunca invocó comportamiento indefinido durante la recuperación de fallos parciales y mantuvo una latencia de inicialización consistente a nivel de microsegundos.
¿Por qué llamar a assume_init en un MaybeUninit<T> no inicializado constituye un comportamiento indefinido incluso si el valor nunca se lee explícitamente después?
Muchos candidatos creen que el comportamiento indefinido solo ocurre cuando accedes físicamente a los datos, como imprimiéndolos o bifurcando sobre ellos. Sin embargo, el sistema de tipos de Rust informa al compilador que existe un T válido inmediatamente al llamar a assume_init. Para tipos con optimizaciones específicas (como bool, char, Option<&T>, o NonNull<T>), el compilador puede generar código que inspecciona el patrón de bits para determinar variantes de enum o validez. Si la memoria contiene bits aleatorios (por ejemplo, 0xFF para un bool), esta inspección desencadena comportamiento indefinido en LLVM (cargando poison o undef). Además, cuando finaliza el alcance, el compilador inserta glue de eliminación para el T, que intentará ejecutar destructores en datos basura, lo que conduce a fallos o vulnerabilidades de seguridad. Por lo tanto, assume_init es un contrato donde el programador garantiza una inicialización válida; violarlo envenena el estado del compilador independientemente de las lecturas explícitas.
¿Cuál es la diferencia entre usar MaybeUninit::write versus std::ptr::write en el puntero devuelto por MaybeUninit::as_mut_ptr(), y cuándo es cada uno apropiado?
MaybeUninit::write es un método seguro que toma propiedad de un T y lo escribe en la ranura no inicializada, devolviendo una referencia mutable a los datos ahora inicializados. Se prefiere cuando tienes el valor listo y deseas acceso seguro inmediato. En contraste, std::ptr::write es una función insegura que escribe un valor en un puntero sin procesar sin leer o eliminar el valor antiguo (lo cual es crítico dado que la memoria no está inicializada). Debes usar ptr::write cuando escribes a través de un puntero sin procesar obtenido de as_mut_ptr() y necesitas evitar las restricciones del verificador de préstamos de write, o cuando implementas abstracciones de bajo nivel donde solo tienes punteros sin procesar. La diferencia clave es que write proporciona garantías de seguridad y seguimiento de duración, mientras que ptr::write requiere verificación manual de que el destino sea válido, esté alineado correctamente y no esté inicializado para evitar violaciones de aliasing o eliminaciones prematuras.
¿Cómo se debe eliminar correctamente un array parcialmente inicializado de MaybeUninit<T> sin filtrar recursos o invocar comportamiento indefinido, y por qué es crítica el orden de operaciones?
Cuando la inicialización falla en el índice i, debes eliminar solo los elementos 0..i. El procedimiento correcto es iterar desde 0 hasta i-1 y llamar a std::ptr::drop_in_place(array[j].as_mut_ptr()). Esto ejecuta el destructor para T sin mover el valor fuera del envoltorio de MaybeUninit (lo que dejaría la ranura en un estado movido, aunque aún técnicamente no inicializado). Es crucial realizar esta limpieza inmediatamente al fallar, antes de devolver el error, para garantizar que el marco de pila se deshaga limpiamente. Si en su lugar intentas utilizar mem::forget en el array o simplemente devuelves, el envoltorio de MaybeUninit se eliminaría (una no operación), pero las instancias de T activas dentro filtrarían sus recursos (como descriptores de archivo o memoria del heap). A la inversa, si eliminas erróneamente los elementos i..N, invocarías un comportamiento indefinido al tratar memoria basura como instancias válidas de T.