--- title: "Qu'est-ce qu'un dangling pointer, et comment Rust le prévient-il au moment de la compilation ?" description: "Pourquoi un dangling pointer est une erreur de compilation en Rust plutôt qu'un crash en production, et comment les lifetimes rendent ce contrôle possible." url: "https://mayorana.ch/fr/blog/dangling-pointer-rust-fr" language: "fr" date: "2025-08-25" author: "Mohamed Bennekrouf" tags: - "rust" - "memory" - "dangling-pointer" - "ownership" - "lifetimes" en_version: "https://mayorana.ch/en/blog/dangling-pointer-rust.md" --- # Qu'est-ce qu'un dangling pointer, et comment Rust le prévient-il au moment de la compilation ? Un **dangling pointer** survient quand un pointeur référence de la mémoire qui a déjà été libérée, menant à un comportement indéfini comme des crashes ou vulnérabilités de sécurité. Dans des langages comme C/C++, c'est un problème courant : ```c int* create_int() { int x = 5; // `x` vit sur le stack return &x; // Retourne un pointeur vers `x`... } // `x` est détruit ici (dangling pointer retourné !) ``` Étape par étape, voici ce que fait le stack dans cette fonction C — et pourquoi le pointeur retourné est déjà invalide avant même que l'appelant le lise :
1. frame empilée frame appelante int* p ; pas encore défini frame create_int x = 5 vit ici 2. return &x frame appelante p = adresse de x frame create_int x = 5 encore vivant 3. frame dépilée p garde l'adresse rien ne l'a invalidé emplacement récupéré réutilisé au prochain appel C compile cela sans broncher : le pointeur survit à la frame qu'il désigne. Rust rejette l'étape 2 d'emblée, donc l'étape 3 ne peut jamais arriver.
Rust élimine les dangling pointers au moment de la compilation en utilisant son modèle d'ownership et système de lifetimes, assurant la memory safety sans overhead runtime.
Rejeté fn dangling() { let s = ..; } s droppé en fin de scope return &s erreur compile-time : référence pendante Accepté fn valid<'a>(s: &'a String) lifetime d'entrée 'a emprunté -> &'a String { s } sortie liée aux données de l'appelant Le borrow checker rejette les références qui survivent au scope de leurs données
## Comment Rust prévient les dangling pointers Rust utilise deux mécanismes clés pour prévenir les dangling pointers : ### 1. Règles d'Ownership + Borrowing - **Règle** : Les références (`&T` ou `&mut T`) ne doivent pas survivre aux données qu'elles pointent. - **Appliqué par** : Le [borrow checker](https://mayorana.ch/fr/blog/borrowing-rules-rust-fr), qui track les scopes de variables et assure que les références restent valides. **Exemple : Rejeté au Compile Time** : ```rust fn dangling() -> &String { // Spécificateur de lifetime manquant ! let s = String::from("hello"); &s // ERREUR: `s` meurt à la fin de la fonction } // Compiler: "returns a reference to dropped data" ``` **Corrigé avec Lifetimes** (Garantie Explicite) : ```rust fn valid_reference<'a>(s: &'a String) -> &'a String { s // OK: Référence retournée liée au lifetime de l'input } ``` ### 2. Annotations de Lifetime - Rust nécessite des **déclarations de lifetime explicites** (`'a`) quand les références traversent les frontières de scope. - Le compilateur assure que toutes les références obéissent à leurs lifetimes assignés, prévenant les références vers mémoire libérée. **Exemple : Struct avec Référence** : ```rust struct Book<'a> { // Doit déclarer lifetime title: &'a str // Référence doit vivre aussi longtemps que `Book` } fn main() { let title = String::from("Rust"); let book = Book { title: &title }; // `book.title` ne peut pas survivre à `title` } ``` ## Pourquoi C'est important | **Langage** | **Risque Dangling Pointer** | **Mécanisme de Sécurité** | |-------------|------------------------------|---------------------------| | C/C++ | Élevé (gestion mémoire manuelle) | Aucun (responsabilité du programmeur) | | Rust | Zéro | Vérifications compile-time (ownership + lifetimes) | ## Pourquoi ça ne peut jamais compiler Le compilateur de Rust garantit : - Pas de références vers mémoire libérée. - Pas de comportement indéfini depuis dangling pointers. - Sécurité sans overhead runtime. **Impact Réel** : Les crates comme `hyper` (HTTP) et `tokio` (async) s'appuient sur ces garanties pour du code sécurisé et performant.