Avant Rust 1.36, les développeurs s'appuyaient sur std::mem::uninitialized pour allouer de la mémoire sur la pile pour des valeurs qui seraient initialisées plus tard. Cette fonction était fondamentalement non sécurisée car elle indiquait au compilateur qu'un T valide existait à cet emplacement mémoire, même si les bits étaient aléatoires. Pour les types avec des invariants de sécurité—tels que bool, char ou des références—cela entraînait un comportement indéfini immédiat, car le compilateur optimisait en se basant sur l'hypothèse que la valeur était valide (par exemple, un bool étant 0 ou 1). RFC 1892 a introduit MaybeUninit<T> comme une abstraction de type union pour indiquer explicitement que la mémoire ne contient pas encore un T valide, résolvant ainsi ce trou de sécurité.
Le problème fondamental découle du traitement de la mémoire non initialisée par LLVM comme étant undef ou poison, associé à la génération automatique de la glue de suppression par Rust. Lorsque le compilateur considère qu'une variable de type T est vivante, il peut émettre des appels de destructeur ou des optimisations de niche. Si T est un bool, un octet non initialisé pourrait contenir la valeur 2, ce qui viole l'invariant de validité des bits. Lire cela lors de la vérification de la suppression ou de l'inspection du discriminateur constitue un comportement indéfini. De plus, si l'initialisation échoue en cours d'exécution à travers un tableau, la glue de suppression pour le type de tableau tenterait de supprimer tous les éléments, interprétant les octets de pile non initialisés comme des pointeurs, entraînant des erreurs d'utilisation après suppression ou de double suppression.
MaybeUninit<T> agit comme un conteneur typé qui peut ou non contenir un T valide. Il empêche le compilateur de supposer l'initialisation, inhibant ainsi l'émission de glue de suppression et les optimisations de motifs de bits invalides. Le programmeur doit suivre manuellement quelles instances sont initialisées, généralement via un tableau d'index séparé ou de booléens. Pour extraire une valeur, on utilise assume_init, assume_init_ref ou std::ptr::read, mais uniquement après avoir prouvé qu'un T valide a été écrit via write ou manipulation de pointeur. L'invariant critique est que assume_init ne doit jamais être appelé sur une mémoire qui n'est pas entièrement initialisée, et lorsqu'on abandonne une structure partiellement initialisée, le programmeur doit manuellement supprimer uniquement les éléments initialisés en utilisant ptr::drop_in_place pour éviter les fuites de ressources.
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) }) }
Vous développez un pilote de carte d'interface réseau no_std où l'allocation de tas est interdite et où la latence doit être déterministe. Vous devez allouer un tableau de taille fixe de 1024 objets Connection sur la pile. Chaque initialisation de Connection implique une écriture dans un registre matériel qui peut échouer si le tampon du NIC est plein. Le défi consiste à garantir que si la 500ème connexion échoue, les 499 précédentes sont correctement fermées (en supprimant les descripteurs de fichiers et en libérant les mappages DMA) tout en laissant les 524 emplacements restants intacts, évitant ainsi tout comportement indéfini lié à la suppression de mémoire non initialisée.
Une approche potentielle consiste à utiliser Default::default() pour pré-initialiser le tableau avec des valeurs sentinelles. Cela nécessite que Connection implémente Default, ce qui est problématique car une connexion « par défaut » acquérirait toujours des ressources du noyau qui doivent être explicitement libérées, compliquant le chemin d'erreur. De plus, construire 1024 connexions factices juste pour les écraser gaspille des cycles d'initialisation et viole les exigences strictes de timing du pilote pour mettre l'interface en ligne.
Une seconde stratégie utilise Vec<Connection> avec with_capacity et un ajout dynamique, suivi de la conversion en tableau fixe. Cela est sûr et idiomatique dans le code utilisateur. Cependant, Vec nécessite un allocateur global, qui n'est pas disponible dans ce contexte de noyau. Cela introduit également des chemins de panique et une fragmentation de la mémoire qui sont inacceptables dans l'espace du noyau, et la conversion en un tableau de taille fixe nécessite des vérifications à l'exécution qui compliquent la logique de gestion des erreurs.
La troisième approche exploite MaybeUninit<[Connection; 1024]> pour allouer l'espace sans initialisation. Les connexions correctement initialisées sont écrites via MaybeUninit::write, et si une erreur se produit à l'index i, nous itérons manuellement de 0 à i-1 et appelons ptr::drop_in_place sur chaque emplacement initialisé avant de retourner l'erreur. En cas de succès, nous transmutons l'ensemble du tableau vers le type initialisé. Nous avons choisi cette solution car elle fournit une allocation de pile sans coût avec des performances déterministes, satisfait la contrainte no_std, et garantit que le nettoyage des ressources n'a lieu que pour les objets réellement initialisés. Le résultat a été un pilote robuste qui n'a jamais invoqué de comportement indéfini lors de la récupération de pannes partielles et a maintenu une latence d'initialisation constante au niveau des microsecondes.
Pourquoi appeler assume_init sur un MaybeUninit<T> non initialisé constitue-t-il un comportement indéfini, même si la valeur n'est jamais explicitement lue par la suite ?
De nombreux candidats pensent que le comportement indéfini ne se produit que lorsque vous accédez physiquement aux données, comme les imprimer ou se baser dessus. Cependant, le système de types de Rust informe le compilateur qu'un T valide existe immédiatement lors de l'appel de assume_init. Pour les types avec des optimisations de niche (comme bool, char, Option<&T>, ou NonNull<T>), le compilateur peut générer du code qui inspecte le motif des bits pour déterminer les variantes d'énumération ou la validité. Si la mémoire contient des bits aléatoires (par exemple, 0xFF pour un bool), cette inspection déclenche un comportement indéfini dans LLVM (chargement de poison ou undef). De plus, lorsque la portée se termine, le compilateur insère une glue de suppression pour le T, qui tentera d'exécuter des destructeurs sur des données corrompues, entraînant des crashes ou des vulnérabilités de sécurité. Ainsi, assume_init est un contrat dans lequel le programmeur garantit une initialisation valide ; le violer empoisonne l'état du compilateur indépendamment des lectures explicites.
Quelle est la différence entre l'utilisation de MaybeUninit::write par rapport à std::ptr::write sur le pointeur retourné par MaybeUninit::as_mut_ptr(), et quand chaque méthode est-elle appropriée ?
MaybeUninit::write est une méthode sûre qui prend possession d'un T et l'écrit dans l'emplacement non initialisé, renvoyant une référence mutable aux données maintenant initialisées. Elle est préférée lorsque vous avez déjà la valeur prête et souhaitez un accès immédiat en toute sécurité. En revanche, std::ptr::write est une fonction unsafe qui écrit une valeur dans un pointeur brut sans lire ou supprimer l'ancienne valeur (ce qui est critique puisque la mémoire est non initialisée). Vous devez utiliser ptr::write lorsque vous écrivez via un pointeur brut obtenu à partir de as_mut_ptr() et devez éviter les restrictions du vérificateur d'emprunt de write, ou lors de l'implémentation d'abstractions bas niveau où vous disposez uniquement de pointeurs bruts. La distinction clé est que write fournit des garanties de sécurité et un suivi de durée de vie, tandis que ptr::write nécessite une vérification manuelle que la destination est valide, correctement alignée et non initialisée pour éviter des violations d'aliasing ou des suppressions prématurées.
Comment supprimer correctement un tableau partiellement initialisé de MaybeUninit<T> sans fuir des ressources ou invoquer un comportement indéfini, et pourquoi l'ordre des opérations est-il critique ?
Lorsque l'initialisation échoue à l'index i, vous devez supprimer uniquement les éléments 0..i. La procédure correcte consiste à itérer de 0 à i-1 et à appeler std::ptr::drop_in_place(array[j].as_mut_ptr()). Cela exécute le destructeur pour T sans déplacer la valeur hors de l'enveloppe MaybeUninit (ce qui laisserait l'emplacement dans un état déplacé, quoique techniquement non initialisé). Il est crucial d'effectuer ce nettoyage immédiatement après l'échec, avant de retourner l'erreur, pour garantir que le cadre de pile est démêlé proprement. Si vous tentiez plutôt d'utiliser mem::forget sur le tableau ou de retourner simplement, l'enveloppe MaybeUninit serait supprimée (une opération no-op), mais les instances de T vivantes à l'intérieur fuiraient leurs ressources (comme des descripteurs de fichiers ou de la mémoire sur tas). À l'inverse, si vous supprimiez par erreur les éléments i..N, vous invoqueriez un comportement indéfini en traitant de la mémoire corrompue comme des instances valides de T.