De std::ptr::addr_of! macro vervult een cruciale rol in onveilige Rust door het mogelijk maken van de creatie van ruwe aanwijzers naar velden zonder de tussenstap van het creëren van een referentie. Bij het omgaan met #[repr(packed)] structs kunnen velden zich op niet-uitgelijnde geheugenoOffsets bevinden, wat de uitlijningsvereisten schendt die inherent zijn aan referentietypes. Proberen een referentie te maken met behulp van de & operator naar dergelijke niet-uitgelijnde gegevens vormt onmiddellijk ongedefinieerd gedrag, ongeacht of de referentie vervolgens wordt gebruikt. De addr_of! macro omzeilt dit door direct een ruwe aanwijzer te materialiseren vanaf het adres van het veld, waarbij de uitlijnings- en geldigheidsinvarianties die door referenties worden gehandhaafd, worden omzeild. Dit onderscheid is van vitaal belang voor solide FFI interacties en lage-niveau geheugenmanipulatie waar gepakte gegevensindelingen gebruikelijk zijn.
Tijdens de ontwikkeling van een hoogpresterende parser voor een legacy binaire protocol kwam het engineeringteam een #[repr(packed)] struct tegen waarin een u32 veld opzettelijk op een offset van 1 byte was geplaatst om overeen te komen met een externe hardwareregisterkaart. De initiële implementatie probeerde dit veld te lenen met &packet.status_register om door te geven aan een validatiefunctie, zich niet bewust dat dit een niet-uitgelijnde referentie creëerde en onmiddellijk ongedefinieerd gedrag veroorzaakte.
De eerste oplossing die werd overwogen, hield in het verwijderen van de packed-attribuut en het handmatig invoegen van paddingbytes om een uitlijning af te dwingen. Deze aanpak garandeerde veiligheid door natuurlijke referentiecreatie mogelijk te maken, maar verstoorde de binaire compatibiliteit met de hardware-specificatie en verspillde geheugenbandbreedte bij het overdragen van grote arrays van deze structs.
De tweede benadering stelde voor om pointer-aritmetiek te gebruiken met unsafe { &*(base_ptr.add(1) as *const u32) } om het veldadres handmatig te berekenen. Hoewel dit de directe veldtoegangssyntax vermeed, materialiseerde het nog steeds een referentie via de &* dereference-operator, wat ongedefinieerd gedrag vormt als de resulterende pointer niet correct is uitgelijnd, zonder verbetering van de veiligheid ten opzichte van de oorspronkelijke naïeve leen en mogelijk misleidend voor toekomstige onderhouders.
Het team koos uiteindelijk de derde oplossing, waarbij het std::ptr::addr_of! gebruikte om een ruwe pointer naar het niet-uitgelijnde veld af te leiden zonder een tussenliggende referentie te creëren. Deze pointer werd vervolgens doorgegeven aan std::ptr::read_unaligned om veilig de waarde over te nemen in een correct uitgelijnde lokale variabele. Deze strategie bewaarde de vereiste geheugenuitleg en voldeed strikt aan Rust's geheugenschema, wat resulteerde in code die rigoureuze tests met Miri doorstond en correct functioneerde op meerdere doelarchitecturen, waaronder ARM en x86_64.
Waarom vormt het creëren van een referentie naar niet-uitgelijnde gegevens ongedefinieerd gedrag, zelfs als de referentie onmiddellijk naar een ruwe pointer wordt cast?
In Rust is de daad van het creëren van een referentie—zoals &packed.field—niet slechts een pointerberekening, maar een verklaring aan de compiler dat het doelgeheugen voldoet aan alle invarianties van dat referentietype, inclusief uitlijning en geldigheid voor leesoperaties. De LLVM backend en Rust's optimizer nemen aan dat deze invarianties onmiddellijk gelden bij referentiecreatie, wat agressieve optimalisaties mogelijk maakt zoals load-store herschikking of speculatieve ladingen. Zelfs als de referentie onmiddellijk wordt gecast naar *const T, kan de optimizer al instructies hebben uitgegeven die veronderstellen dat de toegang uitgelijnd is, of het kan de referentiewaarde markeren als dereferenceable in LLVM metadata, wat leidt tot verkeerde compilatie op architecturen met strikte uitlijningsvereisten. Daarom treedt het ongedefinieerde gedrag op op het moment van referentiecreatie, niet op het punt van derefereren, waardoor het louter bestaan van een niet-uitgelijnde referentie toxisch is voor de correctheid van het programma.
Hoe verschilt addr_of! van het gebruik van as *const _ op een bestaande referentie, en waarom is de macro noodzakelijk?
Bij het schrijven van &packed.field as *const T, maakt de Rust compiler eerst een referentie aan (wat uitlijningscontroles en potentieel UB activeert) en converteert die vervolgens naar een ruwe pointer. Daarentegen werkt std::ptr::addr_of! direct op de plaatsuitdrukking (het veld), die een ruwe pointer genereert zonder ooit een tussenliggende referentie te construeren. Dit is cruciaal omdat de compiler de inhoud van addr_of! beschouwt als een speciale constructie die de geldigheidscontroles voor referenties overslaat, terwijl het as-sleutelwoord een waarde-naar-waarde-conversie uitvoert die vereist dat de bronwaarde (de referentie) geldig is. Het gebruik van de macro garandeert dat de pointerafleiding zelf geen ongedefinieerd gedrag kan introduceren door uitlijningsschendingen, en biedt de enige veilige weg om adressen van potentieel niet-uitgelijnde gegevens te verkrijgen.
Welke aanvullende overwegingen gelden bij het gebruik van addr_of_mut! om pointers naar velden binnen een struct te verkrijgen die een UnsafeCell bevat?
Wanneer een #[repr(packed)] struct een UnsafeCell<T> bevat, vereist het verkrijgen van een gewijzigde pointer naar het interieur zorgvuldige omgang met Rust's aliasingregels. De UnsafeCell biedt interne mutabiliteit, maar het creëren van een gewijzigde referentie (&mut) naar een niet-uitgelijnde UnsafeCell-veld schendt nog steeds de uitlijningsvereisten en is ongedefinieerd gedrag. Kandidaten veronderstellen vaak dat UnsafeCell op de een of andere manier de pointer vrijstelt van uitlijningsregels, maar het vrijstelt alleen van de exclusieve referentie-aliasing garantie (noalias), niet van uitlijning. Het gebruik van addr_of_mut! levert een *mut T op die nog steeds de uitlijningsvereisten van het onderliggende type moet respecteren wanneer deze uiteindelijk wordt gederefereerd of doorgegeven aan UnsafeCell::raw_get, wat vereist dat read_unaligned of write_unaligned worden gebruikt voor daadwerkelijke gegevensaccess.