Historique de la question : L'algorithme Drop Check (dropck) a été introduit pour combler une faille de sécurité dans les premières versions de Rust où des destructeurs génériques pouvaient accéder à des données déjà désallouées. Avant dropck, on pouvait construire une struct contenant une référence à des données allouées sur la pile, implémenter Drop pour le déréférencer, et faire en sorte que les données référencées soient désallouées avant le conteneur, conduisant à des accès après désallocation. Ce problème est devenu critique avec des collections génériques pouvant contenir des données empruntées, nécessitant une analyse conservatrice pour garantir la sécurité du destructeur.
Le problème :
Lorsqu'un type générique Container<T> implémente Drop, le compilateur doit s'assurer que T survit strictement au conteneur pour empêcher le destructeur d'accéder à de la mémoire invalide. Pour les types utilisant des pointeurs bruts (par exemple, *const T), le compilateur manque d'informations sur la durée de vie car les pointeurs bruts ne sont pas suivis par le vérificateur d'emprunts. Sans marqueurs de durée de vie explicites, le compilateur ne peut pas vérifier si le destructeur pourrait déréférencer un pointeur vers des données possédées par le scope actuel qui pourraient être libérées en premier.
La solution :
PhantomData agit comme un marqueur de taille zéro qui simule la propriété ou l'emprunt d'un type T ou d'une durée de vie 'a. En incluant PhantomData<&'a T> dans une struct tenant un pointeur brut, vous informez le compilateur que la struct possède logiquement une référence liée à la durée de vie 'a. L'algorithme Drop Check utilise cela pour faire respecter que la struct ne peut pas survivre à 'a. Si la struct implémente Drop et pourrait potentiellement survivre à son référent, la compilation échoue, empêchant un comportement indéfini.
Vous construisez un parseur de protocole réseau sans copie qui enveloppe un tampon d'octets. Vous définissez Packet<'a> contenant un pointeur brut *const u8 vers un Vec<u8> temporaire reçu du réseau. Vous essayez d'implémenter Drop pour Packet afin de mettre à jour les statistiques de parsing en lisant à travers le pointeur brut. Le danger est que le Vec<u8> soit désalloué lorsque la fonction de réception se termine, mais Packet pourrait être stocké dans une file d'attente pour un traitement ultérieur, entraînant un accès après désallocation lorsque Drop s'exécute.
Tout d'abord, vous envisagez d'utiliser une référence &'a [u8] au lieu d'un pointeur brut. Cela exploite le vérificateur d'emprunts pour garantir que le tampon vive assez longtemps. Cependant, cela restreint considérablement l'API car vous ne pouvez pas déplacer le paquet librement ou le stocker dans des collections qui nécessitent des limites 'static, et cela empêche des motifs auto-référentiels courants dans les parseurs.
Deuxièmement, vous envisagez d'utiliser Rc<Vec<u8>> pour partager la propriété du tampon. Cela garantit que les données restent valides tant qu'un paquet existe. L'inconvénient est le coût de performance du comptage de références et de l'allocation sur le tas, ce qui viole les exigences de traitement réseau à haut débit sans copie et sans frais généraux.
Troisièmement, vous envisagez d'ajouter PhantomData<&'a ()> pour marquer la dépendance de durée de vie tout en conservant le pointeur brut pour la performance. Cependant, cela révèle qu'implémenter Drop est fondamentalement dangereux ici parce que le compilateur ne peut pas garantir que le tampon survit au paquet. Vous choisissez de supprimer l'implémentation de Drop et d'utiliser plutôt une méthode de nettoyage manuelle appelée avant que le tampon soit libéré, ou de passer à Cow<'a, [u8]> pour prendre en charge à la fois les données empruntées et possédées.
Vous sélectionnez l'approche Cow<'a, [u8]>, qui élimine les pointeurs bruts et le besoin de logique Drop non sécurisée. Le résultat est un parseur qui compile avec succès avec des garanties de durée de vie strictes, garantissant qu'aucun paquet ne peut survivre à son tampon sous-jacent tout en maintenant la performance pour le cas emprunté.
Pourquoi le compilateur permet-il d'implémenter Drop pour une struct contenant PhantomData<&'static T>, mais le rejette pour PhantomData<&'a T> où 'a est non statique ?
Lorsque la durée de vie est 'static, les données référencées vivent pendant toute l'exécution du programme, il n'y a donc aucune possibilité de désallocation avant que le destructeur ne s'exécute. Lorsque 'a est une durée de vie locale, les données pourraient être désallouées alors que la struct existe encore, créant un accès à une référence pendante dans Drop. Le compilateur rejette le cas de durée de vie locale parce qu'il ne peut pas prouver que le destructeur n'accèdera pas aux données après leur désallocation, tandis que 'static fournit cette garantie de manière inhérente.
En quoi PhantomData<T> (sémantiques de possession) diffère-t-il de PhantomData<&'a T> (sémantiques d'emprunt) dans le contexte de dropck, et pourquoi le premier ne prévient-il pas la struct d'échapper à son scope ?
PhantomData<T> indique que la struct agit comme si elle possédait un T, ce qui affecte la variance et le contrôle de suppression en supposant que la struct peut libérer un T, mais cela ne lie pas la durée de vie de la struct à une durée de vie empruntée spécifique 'a. Par conséquent, le compilateur suppose que la struct pourrait survivre à n'importe quelles données locales, à moins que T lui-même ne contienne des durées de vie. En revanche, PhantomData<&'a T> contraint explicitement la struct à la durée de vie 'a, garantissant qu'elle ne peut pas survivre à l'emprunt et empêchant ainsi les accès après désallocation dans les destructeurs.
Quel était le but de l'attribut may_dangle (instable/déprécié) en relation avec dropck, et comment s'appliquait-il à des types comme Vec<T> ?
L'attribut #[may_dangle] permettait au code non sécurisé d'informer le compilateur qu'une implémentation Drop d'un type n'accéderait pas au contenu d'un paramètre générique T, même si T ne survit pas strictement au conteneur. Cela était crucial pour des collections comme Vec<T>, qui possèdent leur tampon mais n'ont pas besoin de lire les valeurs T lors de la suppression (elles se contentent de désallouer la mémoire). Les candidats manquent souvent que le Drop Check est conservateur par défaut, supposant que Drop pourrait accéder à tout, et que may_dangle était le mécanisme pour opter pour cette hypothèse pour une flexibilité dans les collections, bien que cela nécessitait un code non sécurisé et des invariants stricts pour éviter d'accéder à des données suspendues.