Gestion de la mémoire

Dans la très grande majorité des cas, en Rust non-unsafe, le compilateur détermine automatiquement quand il peut libérer la mémoire occupée par une valeur du programme. Mais, comme rappelé plus tôt dans ce guide, ce n'est pas une garantie : un code non-unsafe peut mener à des fuites mémoires. Aussi, certaines règles présentées dans ce chapitre ne sont pas strictement unsafe. Cependant,

De manière générale, les fuites mémoires doivent être évitées.

mem::forget et fuites de mémoire

Rust fournit des fonctions spéciales pour réclamer manuellement la mémoire : les fonctions mem::forget et mem::drop du module std::mem (ou core::mem). mem::drop déclenche simplement une récupération prématurée de la mémoire tout en appelant les destructeurs associés lorsque nécessaire, mem::forget quant à elle n'appelle pas ces destructeurs.

#![allow(unused)]
fn main() {
let pair = ('↑', 0xBADD_CAFEu32);
drop(pair);
}

Les deux fonctions sont considérées comme sûres du point de vue mémoire par Rust. Toutefois, mem::forget rendra toute ressource gérée par la valeur libérée inaccessible, mais non libérée.

#![allow(unused)]
fn main() {
let s = String::from("Hello");
forget(s); // Leak memory
}

En particulier, l'utilisation de mem::forget peut causer la rétention en mémoire de ressources critiques, menant à des interblocages et à la persistance de données sensibles en mémoire. C'est pourquoi la fonction mem::forget doit être considérée comme non sécurisée.

#![deny(clippy::mem_forget)]

La bibliothèque standard inclut d'autres moyens d'oublier une valeur :

• Box::leak pour désactiver le destructeur de Box ;
• Box::into_raw pour exploiter une valeur de type Box sous forme d'un pointeur raw dans un bloc unsafe, notamment dans une FFI ;
• ManuallyDrop (dans std::mem ou core::mem) pour assurer la libération manuelle d'une valeur.

Ces alternatives peuvent mener au même type de problème de sécurité, mais ont l'avantage de faire apparaître explicitement leur but.

ManuallyDrop et Box::into_raw passent la responsabilité de la libération de la ressource concernée du compilateur au développeur.

Raw pointers

L'utilisation principale des pointeurs raw est de traduire les pointeurs C en Rust. Comme leur nom l'indique, ces types sont bruts et n'ont pas toutes les capacités des pointeurs intelligents (smart pointer) de Rust. En particulier, leur libération est à la charge du programmeur.

#![allow(unused)]
fn main() {
let boxed = Box::new(String::from("Crab"));
let raw_ptr = Box::into_raw(boxed);
let _ = unsafe { Box::from_raw(raw_ptr) }; // will be freed
}

La réciproque est aussi vraie, c'est-à-dire que les fonctions from_raw ne devraient pas être utilisées sur des raw pointers qui ne sont pas issus de la fonction into_raw associée. En effet, pour les cas comme Rc, la documentation officielle limite explicitement ces fonctions à ce cas d'usage, et, dans le cas de Box, la conversion de pointeurs C en Box n'est pas sûre,

#![allow(unused)]
fn main() {
// Excerpt from the standard library documentation
use std::alloc::{Layout, dealloc};
use std::ptr;

let x = Box::new(String::from("Hello"));
let p = Box::into_raw(x);
unsafe {
   ptr::drop_in_place(p);
   dealloc(p as *mut u8, Layout::new::<String>());
}
}

Mémoire non initialisée

Par défaut, le langage Rust impose que toutes les valeurs soient initialisées, pour prévenir l'utilisation de mémoire non initialisée (à l'exception de l'utilisation de std::mem::uninitialized ou de std::mem::MaybeUninit).

L'utilisation de mémoire non initialisée peut induire deux problèmes de sécurité distincts :

• la libération de mémoire non initialisée (étant également un problème de sûreté mémoire) ;
• la non-libération de mémoire initialisée.