Les pointeurs bruts de Rust (*const T et *mut T) sont des types primitifs qui n'encodent qu'une adresse mémoire sans sémantique de propriété. Contrairement à Box ou Rc, ils ne transportent aucune information sur la taille d'allocation ou les obligations de désallocation. Lorsque #[derive(Clone)] est appliqué à une structure contenant un pointeur brut, le compilateur génère une copie bit à bit de l'adresse, créant deux instances de structure qui aliassent la même allocation sur le tas. Cette copie superficielle conduit inévitablement à une double libération lorsque les deux instances sont supprimées, chaque destructeur tentant de désallouer la même région mémoire.
Le problème central découle de l'écart sémantique entre le système de types et la gestion manuelle de la mémoire. Le compilateur Rust ne peut pas distinguer entre un pointeur qui possède une mémoire sur le tas (nécessitant une copie profonde) et un qui emprunte simplement des données externes. Par conséquent, l'implémentation de Clone manuellement devient obligatoire pour effectuer une copie profonde : allouer une nouvelle mémoire, copier le contenu du pointeur source vers le nouveau tampon, et envelopper la nouvelle adresse dans une instance de structure distincte. Cette opération nécessite intrinsèquement des blocs unsafe car la déréférenciation des pointeurs bruts pour accéder à leurs données tombe en dehors des garanties de sécurité du vérificateur d'emprunts.
La solution implique d'utiliser l'API GlobalAlloc pour reproduire l'allocation originale. L'implémentation doit stocker le Layout utilisé lors de l'allocation initiale, appeler std::alloc::alloc pour créer un nouveau tampon avec la taille et l'alignement identiques, et utiliser ptr::copy_nonoverlapping pour dupliquer les octets. Il est crucial que le code gère l'échec d'allocation via handle_alloc_error, s'assure que le nouveau pointeur est unique à l'instance clonée et garantit que l'original et le clone ne partagent pas la propriété de la ressource sous-jacente.
use std::alloc::{alloc, handle_alloc_error, Layout}; use std::ptr::{self, NonNull}; struct RawBuffer { ptr: NonNull<u8>, layout: Layout, } impl Clone pour RawBuffer { fn clone(&self) -> Self { unsafe { let new_ptr = alloc(self.layout); if new_ptr.is_null() { handle_alloc_error(self.layout); } let new_ptr = NonNull::new_unchecked(new_ptr); ptr::copy_nonoverlapping( self.ptr.as_ptr(), new_ptr.as_ptr(), self.layout.size() ); RawBuffer { ptr: new_ptr, layout: self.layout } } } }
Dans un moteur graphique haute performance intégrant Vulkan, nous avons implémenté une structure AlignedBuffer pour gérer la mémoire visible par le dispositif nécessitant un alignement de 256 octets pour les tampons uniformes. L'application nécessitait le clonage de ces tampons lors de l'initialisation de tâches de calcul asynchrone en arrière-plan qui nécessitaient les mêmes données de vertex initiales sans bloquer le fil principal de rendu. La contrainte critique était que Vec<u8> ne pouvait pas garantir l'alignement spécifique requis par le pilote graphique, forçant l'utilisation directe de std::alloc::alloc et des pointeurs bruts.
Solution A : Derive Clone. Cette approche applique #[derive(Clone)] à la structure AlignedBuffer. Avantages : Aucun temps de développement et aucun bloc de code unsafe. Inconvénients : Effectue une copie superficielle du pointeur brut, causant à la fois l'original et le clone à pointer vers la même mémoire ; lorsque les deux sont supprimés, l'application plante avec une double libération ou corrompt le tas du pilote GPU.
Solution B : Convertir en Vec lors du clonage. Cela alloue un Vec<u8> avec les données, le clone en utilisant des méthodes sécurisées, puis se reconvertit en un pointeur brut avec un alignement approprié. Avantages : Code Rust entièrement sûr utilisant des abstractions de la bibliothèque standard. Inconvénients : Nécessite deux allocations et deux copies par clone, viole l'exigence d'alignement de 256 octets de Vec, et introduit une latence inacceptable dans le chemin de rendu chaud.
Solution C : Copie profonde manuelle avec unsafe. Nous implémentons Clone en extrayant le Layout stocké, en appelant std::alloc::alloc, en utilisant ptr::copy_nonoverlapping pour dupliquer les octets, et en construisant un nouveau AlignedBuffer avec des gardes ManuallyDrop pour éviter les fuites lors d'un panic. Avantages : Maintient l'alignement requis, effectue une seule allocation par clone, et respecte les sémantiques de zéro copie pour le transfert de données. Inconvénients : Nécessite un code unsafe, doit gérer manuellement les conditions de mémoire insuffisante, et risque des fuites de mémoire si le constructeur panique après l'allocation mais avant le stockage du pointeur.
Nous avons sélectionné Solution C car le contrat d'alignement avec le pilote Vulkan était non négociable, et le budget de performance ne laissait aucune place à l'overhead de conversion de Vec. L'implémentation manuelle a soigneusement utilisé des gardes ManuallyDrop lors de la construction pour garantir le nettoyage en cas de panique. Le résultat était une boucle de rendu stable à 60fps sans fuites de mémoire détectées après 48 heures de tests de stress, passant avec succès la validation des emprunts empilés de Miri.
Pourquoi le compilateur permet-il #[derive(Clone)] sur des structures contenant des pointeurs bruts si cela crée un risque de double libération ?
Le compilateur Rust considère les pointeurs bruts comme des types Copy, ce qui signifie que la duplication bit à bit est définie comme l'opération de clonage. Puisque Clone est automatiquement implémenté pour tout type Copy via la copie bit à bit, #[derive(Clone)] invoque simplement cette copie superficielle pour le champ du pointeur. Le compilateur n'a pas de connaissance sémantique que le pointeur représente une mémoire sur le tas possédée ; il traite le pointeur comme une adresse entière opaque. Cette distinction entre "copier le pointeur" et "cloner l'allocation" est entièrement de la responsabilité du développeur à encoder manuellement par une implémentation personnalisée.
Qu'est-ce qui nous empêche d'implémenter le trait Copy au lieu de Clone pour éviter d'écrire du code unsafe ?
Copy et Drop sont des traits mutuellement exclusifs en Rust. Si un type implémente Drop pour désallouer la mémoire sur le tas pointée par le pointeur brut, il ne peut pas implémenter Copy. Même si cette restriction était levée, les sémantiques de Copy impliquent que la duplication bit à bit crée deux copies indépendantes et valides de la valeur. Pour les pointeurs bruts possédant une mémoire sur le tas, cela entraînerait toujours des doubles libérations car les deux copies tenteraient de libérer la même adresse mémoire lorsqu'elles sortent du champ d'application. Copy est réservé strictement aux types sans logique de destruction personnalisée, tels que les entiers ou les références immuables.
Comment std::ptr::NonNull<T> améliore-t-il les pointeurs bruts lors de l'implémentation de Clone, et élimine-t-il le besoin de blocs unsafe ?
NonNull<T> fournit un enrobage non nul et covariant autour de *mut T, offrant une meilleure sécurité de type et garantissant que le pointeur n'est jamais nul. Cela permet des optimisations du compilateur comme le remplissage de valeur niche et élimine les vérifications de pointe nulle. Cependant, NonNull reste une abstraction de pointeur brut qui ne transmet aucune information de propriété ou de gestion automatique de la mémoire. Implémenter Clone pour une structure contenant NonNull<T> nécessite toujours des blocs unsafe pour déréférencer le pointeur et effectuer la copie profonde. L'avantage réside dans la clarté de l'API et la correction des variantes, mais l'exigence fondamentale de gérer manuellement l'allocation et d'éviter les doubles libérations demeure inchangée.