Prima di Rust 1.36, gli sviluppatori si affidavano a std::mem::uninitialized per allocare memoria nello stack per valori che sarebbero stati inizializzati in seguito. Questa funzione era fondamentalmente insicura perché diceva al compilatore che un valido T esisteva in quella posizione di memoria, anche se i bit erano casuali. Per tipi con invarianti di sicurezza—come bool, char o riferimenti—questo portava a comportamenti indefiniti immediati, poiché il compilatore avrebbe ottimizzato sulla base dell'assunzione che il valore fosse valido (ad esempio, un bool che fosse 0 o 1). RFC 1892 ha introdotto MaybeUninit<T> come astrazione simile a un'unione per denotare esplicitamente la memoria che non contiene ancora un valido T, risolvendo questa falla di sicurezza.
Il problema principale deriva dal trattamento della memoria non inizializzata da parte di LLVM come undef o poison, unito alla generazione automatica del glue di drop in Rust. Quando il compilatore crede che una variabile di tipo T sia attiva, potrebbe emettere chiamate al distruttore o ottimizzazioni di nicchia. Se T è un bool, un byte non inizializzato potrebbe contenere il valore 2, il che viola l'invariante di validità dei bit. Leggere questo durante i controlli di drop o l'ispezione del discriminatore costituisce un comportamento indefinito. Inoltre, se l'inizializzazione fallisce a metà attraverso un array, il glue di drop per il tipo array cercherebbe di rilasciare tutti gli elementi, interpretando i byte non inizializzati nello stack come puntatori e causando errori di use-after-free o double-free.
MaybeUninit<T> agisce come un contenitore tipizzato che può o meno contenere un valido T. Impedisce al compilatore di assumere inizializzazione, inibendo così l'emissione del glue di drop e le ottimizzazioni di pattern di bit non validi. Il programmatore deve monitorare manualmente quali istanze sono state inizializzate, tipicamente tramite un indice separato o un array booleano. Per estrarre un valore, si utilizza assume_init, assume_init_ref o std::ptr::read, ma solo dopo aver scritto provabilmente un valido T tramite write o manipolazione di puntatori. L'invariante cruciale è che assume_init non deve mai essere chiamato su memoria che non è completamente inizializzata e, quando si abbandona una struttura parzialmente inizializzata, il programmatore deve manualmente rilasciare solo gli elementi inizializzati usando ptr::drop_in_place per evitare perdite di risorse.
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) }) }
Stai sviluppando un driver di kernel no_std per una scheda di interfaccia di rete dove l'allocazione heap è vietata e la latenza deve essere deterministica. Devi allocare una tabella di dimensioni fisse di 1024 oggetti Connection nello stack. Ogni inizializzazione di Connection coinvolge una scrittura su un registro hardware che può fallire se il buffer NIC è pieno. La sfida è garantire che se la 500esima connessione fallisce, le precedenti 499 siano chiuse correttamente (rilasciando i descrittori di file e le mappature DMA) mentre i restanti 524 slot rimangono intatti, evitando qualsiasi comportamento indefinito dal rilascio di memoria non inizializzata.
Uno dei potenziali approcci prevede l'utilizzo di Default::default() per pre-inizializzare l'array con valori sentinella. Ciò richiede che Connection implementi Default, il che è problematico perché una connessione "predefinita" acquisirebbe comunque risorse del kernel che devono essere esplicitamente rilasciate, complicando il percorso di errore. Inoltre, costruire 1024 connessioni dummy solo per sovrascriverle spreca cicli di inizializzazione e viola i rigorosi requisiti temporali del driver per mettere online l'interfaccia.
Una seconda strategia utilizza Vec<Connection> con with_capacity e inserimento dinamico, seguito dalla conversione in un array fisso. Questo è sicuro e idiomatico nel codice dello spazio utente. Tuttavia, Vec richiede un allocatore globale, non disponibile in questo contesto di kernel. Introduce anche potenziali percorsi di panico e frammentazione della memoria, inaccettabili nello spazio del kernel, e la conversione in un array di dimensioni fisse richiede controlli a runtime che complicano la logica di gestione degli errori.
Il terzo approccio sfrutta MaybeUninit<[Connection; 1024]> per allocare lo spazio senza inizializzazione. Le connessioni inizializzate con successo vengono scritte tramite MaybeUninit::write, e se si verifica un errore all'indice i, iteriamo manualmente da 0 a i-1 e chiamiamo ptr::drop_in_place su ciascuno slot inizializzato prima di restituire l'errore. In caso di successo, trasmutiamo l'intero array nel tipo inizializzato. Abbiamo selezionato questa soluzione perché offre allocazione stack senza costi con prestazioni deterministiche, soddisfa il vincolo no_std e garantisce che la pulizia delle risorse avvenga solo per oggetti realmente inizializzati. Il risultato è stato un driver robusto che non ha mai invocato comportamenti indefiniti durante il recupero da un fallimento parziale e ha mantenuto una latenza di inizializzazione costante a livello di microsecondi.
Perché chiamare assume_init su un MaybeUninit<T> non inizializzato costituisce comportamento indefinito anche se il valore non viene mai esplicitamente letto dopo?
Molti candidati credono che il comportamento indefinito si verifichi solo quando si accede fisicamente ai dati, come stamparli o basarsi su di essi. Tuttavia, il sistema di tipi di Rust informa il compilatore che un valido T esiste immediatamente al momento della chiamata di assume_init. Per tipi con ottimizzazioni di nicchia (come bool, char, Option<&T> o NonNull<T>), il compilatore può generare codice che ispeziona il pattern di bit per determinare varianti di enum o validità. Se la memoria contiene bit casuali (ad esempio, 0xFF per un bool), questa ispezione attiva un comportamento indefinito in LLVM (caricando poison o undef). Inoltre, quando termina l'ambito, il compilatore inserisce il glue di drop per il T, che tenterà di eseguire i distruttori su dati spazzatura, portando a arresti anomali o vulnerabilità di sicurezza. Quindi, assume_init è un contratto in cui il programmatore garantisce un'inizializzazione valida; violarlo avvelena lo stato del compilatore indipendentemente dai letti espliciti.
Qual è la differenza tra utilizzare MaybeUninit::write rispetto a std::ptr::write sul puntatore restituito da MaybeUninit::as_mut_ptr(), e quando è appropriato ciascuno?
MaybeUninit::write è un metodo sicuro che prende possesso di un T e lo scrive nello slot non inizializzato, restituendo un riferimento mutabile ai dati ora inizializzati. È preferito quando si ha il valore pronto e si desidera un accesso immediato e sicuro. Al contrario, std::ptr::write è una funzione insicura che scrive un valore in un puntatore grezzo senza leggere o rilasciare il valore precedente (cosa critica poiché la memoria è non inizializzata). Devi utilizzare ptr::write quando scrivi tramite un puntatore grezzo ottenuto da as_mut_ptr() e devi evitare le restrizioni del borrow checker di write, o quando implementi astrazioni a basso livello dove hai solo puntatori grezzi. La distinzione chiave è che write fornisce garanzie di sicurezza e tracciamento della vita, mentre ptr::write richiede una verifica manuale che la destinazione sia valida, correttamente allineata e non inizializzata per evitare violazioni di aliasing o rilasci prematuri.
Come si può correttamente rilasciare un array parzialmente inizializzato di MaybeUninit<T> senza far perdere risorse o invocare comportamento indefinito, e perché è critica l'ordine delle operazioni?
Quando l'inizializzazione fallisce all'indice i, devi rilasciare solo gli elementi 0..i. La procedura corretta è iterare da 0 a i-1 e chiamare std::ptr::drop_in_place(array[j].as_mut_ptr()). Questo esegue il distruttore per T senza spostare il valore fuori dal wrapper MaybeUninit (cosa che lascerebbe lo slot in uno stato spostato, sebbene ancora tecnicamente non inizializzato). È cruciale eseguire questa pulizia immediatamente al verificarsi del fallimento, prima di restituire l'errore, per garantire che il frame dello stack venga srotolato correttamente. Se invece tentassi di usare mem::forget sull'array o semplicemente restituisci, il wrapper MaybeUninit verrebbe rilasciato (un no-op), ma le istanze T attive all'interno potrebbero far perdere le loro risorse (come gestori di file o memoria heap). Al contrario, se accidentalmente rilasciassi elementi i..N, invocheresti comportamento indefinito trattando la memoria spazzatura come valide istanze di T.