L'attribut #[repr(packed)] provient des exigences de programmation système où la disposition de la mémoire doit correspondre aux spécifications externes—comme les registres matériels ou les protocoles réseau—en éliminant les octets de remplissage entre les champs. Alors que Rust garantit normalement que les références sont alignées aux exigences de leur type pointeur, les structs packagées forcent les champs à des décalages d'octets séquentiels indépendamment de l'alignement, plaçant potentiellement un u32 à une adresse non divisible par quatre. Tenter de créer une référence (& ou &mut) à un champ désaligné constitue un comportement indéfini immédiat, car le compilateur et LLVM supposent des adresses alignées pour des optimisations telles que la vectorisation ou les opérations atomiques. Pour accéder en toute sécurité aux données, il faut éviter complètement de créer des références intermédiaires, en utilisant à la place les macros addr_of! et addr_of_mut! pour obtenir directement des pointeurs bruts, puis employer ptr::read_unaligned ou ptr::write_unaligned pour copier des données sans hypothèses sur l'alignement.
use std::ptr::{addr_of, read_unaligned}; #[repr(packed)] struct Packet { flags: u8, timestamp: u64, // Potentiellement à l'offset 1, désaligné } fn get_timestamp(p: &Packet) -> u64 { // UB: &p.timestamp créerait une référence désalignée let raw_ptr = addr_of!(p.timestamp); unsafe { read_unaligned(raw_ptr) } }
Tout en développant un analyseur sans copie pour un protocole financier binaire (FIX), l'équipe a besoin d'une struct correspondant exactement au format de transmission : un type de message u8 suivi immédiatement d'un timestamp u64 sans remplissage. L'implémentation initiale utilisait #[repr(packed)] avec un accès direct aux champs, ce qui a causé des fautes de segmentation intermittentes sur les architectures ARM où l'accès désaligné piège dans le noyau.
Plusieurs solutions ont été évaluées. Premièrement, la reconstruction manuelle octet par octet utilisant des opérations de décalage et d’OR : cela a éliminé les problèmes d'alignement mais a introduit une surcharge CPU significative par paquet et une logique de manipulation de bits sujette aux erreurs qui compliquait l'audit. Deuxièmement, l'utilisation de #[repr(C)] avec des champs de remplissage explicites pour forcer l'alignement : cela a préservé la sécurité mais a brisé la compatibilité du protocole en modifiant les offsets d'octets des champs suivants, nécessitant des copies de mémoire coûteuses pour réorganiser les données avant la transmission. Troisièmement, conserver #[repr(packed)] mais accéder aux champs uniquement par des pointeurs bruts avec des lectures désalignées : cela a maintenu la disposition mémoire exacte tout en évitant le comportement indéfini en ne créant jamais des références alignées au champ timestamp.
L'équipe a choisi la troisième approche, implémentant une méthode d'obtention qui utilisait addr_of!(self.timestamp) suivie de ptr::read_unaligned pour retourner la valeur du timestamp. Cela a éliminé les plantages sur ARM et x86_64 tout en préservant l'architecture sans copie, réduisant la latence de 40 % par rapport à l'approche de reconstruction par octets.
Pourquoi créer une référence à un champ désaligné constitue-t-il un comportement indéfini même sur les architectures qui prennent en charge l'accès désaligné ?
Bien que les processeurs x86_64 tolèrent les chargements désalignés en matériel, les règles de comportement indéfini de Rust sont plus strictes que les capacités matérielles pour permettre des optimisations agressives. Lorsque le compilateur voit &u32, il suppose que l'adresse est alignée sur quatre octets, ce qui lui permet d'émettre des instructions SIMD, d'optimiser les vérifications d'alignement ultérieures, ou de réorganiser les opérations mémoire. Violer cette hypothèse—même sur un matériel tolérant—permet au compilateur de mal compiler le code, provoquant potentiellement des plantages ou une corruption silencieuse des données sur les versions futures du compilateur ou sur des architectures différentes.
En quoi la macro addr_of! diffère-t-elle sémantiquement de l'opérateur & lorsqu'elle est appliquée aux champs de struct packagée ?
L'opérateur & crée conceptuellement d'abord une référence, puis la contraint à un pointeur brut si elle est assignée à un, déclenchant ainsi immédiatement la vérification de validité d'alignement. En revanche, addr_of! est une macro intégrée qui calcule l'adresse directement sans créer de référence intermédiaire, contournant ainsi complètement l'exigence d'alignement. Cette distinction est cruciale car addr_of! retourne un *const T qui peut être désaligné, tandis que &field serait UB si le champ est désaligné, même s'il est immédiatement converti en pointeur.
Pourquoi implémenter Drop pour une struct packagée contenant des champs non-Copy est-il problématique, et comment peut-on implémenter en toute sécurité une destruction personnalisée ?
La méthode Drop::drop reçoit &mut self, qui est aligné (la struct elle-même maintient un alignement global), mais faire tomber des champs individuels nécessite d'appeler leurs destructeurs avec &mut Field. Si un champ a un alignement plus élevé que celui du début de la struct et est donc désaligné, créer &mut Field pour invoquer Drop est un comportement indéfini. Pour faire tomber en toute sécurité de telles structs, il faut envelopper les champs non-Copy dans ManuallyDrop, puis dans l'implémentation personnalisée de Drop, utiliser ptr::read_unaligned ou ptr::drop_in_place sur des pointeurs bruts obtenus par addr_of_mut!, s'assurant que le destructeur s'exécute sans jamais créer une référence alignée vers le champ désaligné.