Geschiedenis van de vraag: Het Drop Check (dropck) algoritme werd geïntroduceerd om een fout in de klankvastheid van vroege Rust versies te dichten, waar generieke destructors toegang konden krijgen tot gegevens die al waren vrijgegeven. Voor dropck kon men een struct construeren die een referentie naar stack-gealloceerde gegevens vasthield, Drop implementeren om deze dereferentie te maken, en de gerefereerde gegevens laten vallen voordat de container, leidend tot use-after-free. Dit probleem werd kritiek met generieke collecties die mogelijk geleende gegevens bevatten, wat een conservatieve analyse vereiste om de veiligheid van destructors te waarborgen.
Het probleem:
Wanneer een generiek type Container<T> Drop implementeert, moet de compiler ervoor zorgen dat T strikt langer leeft dan de container om te voorkomen dat de destructor toegang heeft tot ongeldig geheugen. Voor types die rauwe pointers gebruiken (bijv. *const T), mist de compiler levensduurinformatie omdat rauwe pointers niet worden gevolgd door de borrow checker. Zonder expliciete levensduurmarkeringen kan de compiler niet verifiëren of de destructor een pointer naar gegevens kan derefereren die eigendom zijn van de huidige scope en die mogelijk eerder kunnen worden vrijgegeven.
De oplossing:
PhantomData fungeert als een nul-grootte marker die eigendom of lenen van een type T of levensduur 'a simuleert. Door PhantomData<&'a T> op te nemen in een struct die een rauwe pointer vasthoudt, informeer je de compiler dat de struct logisch een referentie bevat die gebonden is aan levensduur 'a. Het Drop Check algoritme gebruikt dit om af te dwingen dat de struct niet langer mag leven dan 'a. Als de struct Drop implementeert en mogelijk langer zou leven dan haar referent, mislukt de compilatie, waardoor ongedefinieerd gedrag wordt voorkomen.
Je bouwt een zero-copy netwerkprotocolparser die een bytebuffer wikkelt. Je definieert Packet<'a> met daarin een rauwe pointer *const u8 naar een tijdelijke Vec<u8> die is ontvangen van de netstack. Je probeert Drop te implementeren voor Packet om parsestatistieken bij te werken door door de rauwe pointer te lezen. Het gevaar is dat de Vec<u8> wordt vrijgegeven wanneer de ontvangfunctie eindigt, maar Packet misschien in een wachtrij wordt opgeslagen voor latere verwerking, wat leidt tot een use-after-free wanneer Drop wordt uitgevoerd.
Eerst overweeg je een referentie &'a [u8] in plaats van een rauwe pointer. Dit benut de borrow checker om ervoor te zorgen dat de buffer lang genoeg leeft. Echter, dit beperkt de API aanzienlijk omdat je het pakket niet vrij kunt verplaatsen of kunnen opslaan in collecties die 'static-beperkingen vereisen, en het voorkomt zelf-referentiele patronen die gebruikelijk zijn in parsers.
Ten tweede overweeg je Rc<Vec<u8>> te gebruiken om het eigendom van de buffer te delen. Dit zorgt ervoor dat de gegevens geldig blijven zolang er een pakket bestaat. Het nadeel is de prestatiekosten van referentietelling en heapallocatie, wat de zero-copy, zero-overhead vereisten van hoge doorvoer netwerkverwerking schendt.
Ten derde overweeg je PhantomData<&'a ()> toe te voegen om de levensduur afhankelijkheid te markeren terwijl je de rauwe pointer voor prestaties behoudt. Echter, dit onthult dat het implementeren van Drop fundamenteel onveilig is omdat de compiler niet kan garanderen dat de buffer langer leeft dan het pakket. Je kiest ervoor om de Drop implementatie te verwijderen en in plaats daarvan een handmatige opruimfunctie te gebruiken die wordt aangeroepen voordat de buffer wordt vrijgegeven, of overschakelen naar Cow<'a, [u8]> om zowel geleende als eigendom gegevens te ondersteunen.
Je kiest voor de Cow<'a, [u8]> benadering, die rauwe pointers en de noodzaak voor onveilige Drop logica elimineert. Het resultaat is een parser die succesvol compileert met strikte levensduur garanties, wat ervoor zorgt dat geen enkel pakket langer kan leven dan zijn onderliggende buffer terwijl de prestaties voor de geleende case behouden blijven.
Waarom staat de compiler het implementeren van Drop voor een struct met PhantomData<&'static T> toe, maar weigert het voor PhantomData<&'a T> waar 'a niet-statisch is?
Wanneer de levensduur 'static is, leeft de gerefereerde data gedurende de hele programmacommunicatie, waardoor er geen mogelijkheid is tot vrijgave voordat de destructor draait. Wanneer 'a een lokale levensduur is, kunnen de gegevens worden vrijgegeven terwijl de struct nog bestaat, wat een dangling reference-toegang in Drop creëert. De compiler weigert de lokale levensduur geval omdat ze niet kan bewijzen dat de destructor niet toegang heeft tot de gegevens nadat deze is vrijgegeven, terwijl 'static deze garantie inherent biedt.
Hoe verschilt PhantomData<T> (bezitsemantiek) van PhantomData<&'a T> (lenensemantiek) in de context van dropck, en waarom voorkomt de eerste niet dat de struct zijn scope ontvlucht?
PhantomData<T> geeft aan dat de struct zich gedraagt alsof hij een T bezit, wat de variatie en drop-check beïnvloedt door aan te nemen dat de struct een T kan laten vallen, maar het bindt de levensduur van de struct niet aan een specifieke geleende levensduur 'a. Daarom gaat de compiler ervan uit dat de struct langer kan leven dan welke lokale gegevens ook, tenzij T zelf levensduren bevat. In tegenstelling hiermee beperkt PhantomData<&'a T> de struct expliciet tot levensduur 'a, waardoor ervoor gezorgd wordt dat hij niet langer kan leven dan de lening en daardoor use-after-free in destructors voorkomt.
Wat was het doel van de may_dangle attribuut (instabiel/deprecated) in relatie tot dropck, en hoe paste het bij types zoals Vec<T>?
De #[may_dangle] attribuut stelde onveilige code in staat de compiler te informeren dat de Drop implementatie van een type geen toegang zou hebben tot de inhoud van een generieke parameter T, zelfs als T niet strikt langer dan de container zou leven. Dit was cruciaal voor collecties zoals Vec<T>, die eigendom hebben van hun buffer maar de T-waarden niet hoeven te lezen tijdens het laten vallen (ze dealloceren gewoon geheugen). Kandidaten missen vaak dat Drop Check standaard conservatief is, ervan uitgaande dat Drop mogelijk overal toegang heeft, en dat may_dangle het mechanisme was om van deze veronderstelling af te wijken voor flexibiliteit in collecties, hoewel het onveilige code en strikte invarianten vereiste om toegang tot hangende gegevens te voorkomen.