Antwoord.

Achtergrond:

Rust is oorspronkelijk ontworpen als een taal met een focus op geheugenveiligheid. Echter, in sommige scenario's — zoals bij het werken met FFI of low-level allocators — moet je raw pointers gebruiken en handmatig omgaan met dynamisch geheugen. Dergelijke taken komen voor in systeemprogrammering en prestatieoptimalisatie. Daarom is het belangrijk om te weten hoe Rust geheugenlekken, dangling pointers en use-after-free voorkomt.

Probleem:

Raw pointers (*const T, *mut T) zijn niet geïntegreerd in Rust's eigendoms- en referentiemechanisme: ze kunnen naar ongeldige geheugenlocaties wijzen, verkeerd worden vrijgegeven of helemaal niet worden vrijgegeven. Fouten bij het werken met raw pointers kunnen leiden tot UB (undefined behavior), crashes, beveiligingskwetsbaarheden of geheugenlekken.

Oplossing:

In plaats van raw pointers wordt aanbevolen om veilige types te gebruiken — Box, Rc, Arc, en voor tijdelijke referenties — borrow-referenties. Als raw pointers echt nodig zijn (bijvoorbeeld voor het werken met C API), wordt al het werk verpakt in unsafe-blokken, wordt er aandacht besteed aan Drop, en worden, waar mogelijk, crates zoals NonNull gebruikt. Een andere techniek is RAII-wrapping en het minimaliseren van de levensduur van de pointer.

Codevoorbeeld:

fn allocate_in_heap() -> Box<i32> {
    Box::new(100)
} // geheugen wordt automatisch vrijgegeven

// met raw pointer
unsafe fn leak_memory() {
    let ptr = libc::malloc(4) as *mut i32;
    if !ptr.is_null() {
        *ptr = 42;
        // libc::free(ptr); // als je vergeet vrij te geven — lek!
    }
}

Belangrijke kenmerken:

Veilige types (Box, Rc, Arc) volgen de geheugenbeheersingsregels
Unsafe raw pointers zijn alleen toegestaan in specifieke scenarios en vereisen handmatige vrijgave
Drop-trait en RAII benaderingen beschermen tegen de meeste lekken

Vragen met een valstrik.

Garandeert Box automatische opruiming van alle ingesloten waarden bij verwijdering van Box?

Ja, wanneer Box<T> wordt verwijderd, roept de destructor eerst de opruiming van de wrapper aan, dan recursief — van alle gegevens die erin zijn ingesloten (tot de elementen van Vec of andere Box binnen struct T).

Is het veilig om een raw pointer van een structuur door meerdere functies door te geven, zonder het risico op use-after-free?

Nee, een raw pointer bevat geen informatie over de levensduur van het object. De compiler kan de veiligheid niet controleren, dus ligt de verantwoordelijkheid volledig bij de ontwikkelaar: als het object is vrijgegeven, zal de raw pointer naar een lege locatie wijzen.

Kan Rust Drop twee keer aanroepen op hetzelfde adres als we handmatig free of drop_in_place gebruiken?

Ja, als je na handmatige vrijgave een andere Box/pointer laat verwijzen naar hetzelfde blok, zal bij de vernietiging van de tweede instantie Drop opnieuw worden aangeroepen, wat UB veroorzaakt. Je moet nooit handmatig iets vrijgeven dat wordt beheerd door Box, Vec, enz.

Veelvoorkomende fouten en anti-patronen

Inbreuk op de eigendom: handmatig vrijkomen van een resource + automatische destructor (double free)
Geheugenlekken door mem::forget of niet-vrijgegeven raw-pointer
Doorgeven van een pointer buiten de levensduur van de inhoud
Niet-geinitieerd geheugen (alloca zonder write)

Voorbeeld uit de praktijk

Negatieve case

Een programmeur accepteerde een raw pointer uit een externe C-bibliotheek, heeft deze niet vrijgegeven na gebruik of perfndo-dealloc maakte een fout bij de levensduur.

Voordelen:

Snelle integratie met C API

Nadelen:

Geheugenlekken tot uitputting van RAM
Crashes door use-after-free

Positieve case

Er wordt een RAII-wrapper met Drop gebruikt, de pointer wordt ingekapseld via Box of NonNull, alles wordt veilig vernietigd aan het einde van de scope.