unsafe & FFI, ou le dernier recours encapsulé unsafe & FFI, or the encapsulated last resort

unsafe ne désactive aucune règle : il transfère leur preuve du compilateur vers toi.unsafe disables no rule: it transfers their proof from the compiler to you.

Voici le dernier numéro de la série, et son sujet est l'unique porte de sortie du système de preuve. Pendant huit volumes, on a laissé le compilateur prouver la sûreté : la possession, les durées de vie, l'absence de course. unsafe est la porte par laquelle on en sort. Mais attention au contre-sens le plus répandu : unsafe ne « désactive » pas les règles de Rust. Il fait une seule chose — autoriser cinq opérations que le compilateur ne sait pas vérifier (déréférencer un pointeur brut, appeler une fonction unsafe, toucher un static mutable, implémenter un trait unsafe, lire un champ d'union) — à une condition : que ce soit toi, désormais, qui garantisses les invariants que le compilateur vérifiait à ta place. Le contrat qu'il tenait, tu le signes. Le tenir, et tout va bien ; le rompre, et c'est l'undefined behavior — le bug que rien ne rattrape.Here's the series' final issue, and its subject is the single exit from the proof system. For eight volumes, we let the compiler prove safety: ownership, lifetimes, the absence of races. unsafe is the door you leave through. But beware the most widespread misreading: unsafe does not 'disable' Rust's rules. It does one thing — allow five operations the compiler can't verify (dereference a raw pointer, call an unsafe function, touch a mutable static, implement an unsafe trait, read a union field) — on one condition: that it's now you who guarantees the invariants the compiler checked in your place. The contract it held, you sign. Uphold it, and all is well; break it, and it's undefined behavior — the bug nothing catches.

let x = 42;
let ptr = &x as *const i32;     // un pointeur brut : le CRÉER est sûr…

let valeur = unsafe { *ptr };   // …le DÉRÉFÉRENCER ne l'est pas. unsafe = « je PROMETS que
                                //   ce pointeur est valide, aligné, et pointe une donnée vivante ».
// le compilateur ne vérifie plus cette promesse : c'est TOI qui réponds de sa véracité.
// la tenir → tout va bien. la rompre → undefined behavior, le pire des bugs.

Dans un bloc unsafe, le borrow checker est toujours allumé.Inside an unsafe block, the borrow checker is still on.

La surprise du numéro corrige l'image la plus répandue et la plus fausse : « unsafe, c'est le mode C, tout est permis ». Non. À l'intérieur d'un bloc unsafe, le borrow checker fonctionne exactement comme dehors : tu ne peux toujours pas avoir deux &mut sur la même donnée, tu dois toujours respecter les durées de vie, les moves restent vérifiés. unsafe n'ouvre que cinq portes précises — déréférencer un pointeur brut, appeler une fonction unsafe, toucher un static mutable, implémenter un trait unsafe, lire un champ d'union — et rien de plus. C'est une permission chirurgicale, pas un interrupteur général. Cette étroitesse est une bonne nouvelle : la zone où tu dois faire la preuve toi-même est minuscule, circonscrite à ces cinq opérations. Tout le reste de ton code, même dans un bloc unsafe, reste prouvé par le compilateur.The issue's surprise corrects the most widespread and most false image: 'unsafe is C mode, anything goes'. No. Inside an unsafe block, the borrow checker works exactly as outside: you still can't have two &mut on the same data, you must still respect lifetimes, moves are still checked. unsafe opens only five precise doors — dereference a raw pointer, call an unsafe function, touch a mutable static, implement an unsafe trait, read a union field — and nothing more. It's a surgical permission, not a master switch. That narrowness is good news: the zone where you must do the proof yourself is tiny, confined to those five operations. All the rest of your code, even in an unsafe block, stays proven by the compiler.

let mut data = vec![1, 2, 3];

unsafe {
    let r1 = &mut data;
    let r2 = &mut data;       // ✕ error[E0499]: cannot borrow `data` as mutable more than once
    r1.push(4);               //   le bloc unsafe N'A PAS désactivé le borrow checker.
}
// la règle « aliasing XOR mutation » du Vol 1 tient TOUJOURS ici. unsafe ne l'a pas levée :
// il n'a jamais été question de désactiver les règles, seulement d'autoriser cinq opérations.

Le même E0499 que partout ailleurs. Le bloc unsafe n'a strictement rien changé à l'analyse des emprunts : la règle « aliasing XOR mutation » du Vol 1 s'applique à l'identique. C'est la preuve par le code que unsafe n'est pas un bypass. Si tu veux deux &mut sur la même donnée, unsafe ne t'y aide pas — il faudrait passer par des pointeurs bruts (porte n°1) et prouver toi-même qu'ils ne s'aliasent pas. Le compilateur ne te lâche pas la main ; il te tend juste un outil de plus, et la responsabilité qui va avec.The same E0499 as everywhere else. The unsafe block changed strictly nothing in the borrow analysis: Vol 1's 'aliasing XOR mutation' rule applies identically. It's proof by code that unsafe isn't a bypass. If you want two &mut on the same data, unsafe doesn't help — you'd go through raw pointers (door 1) and prove yourself they don't alias. The compiler doesn't let go of your hand; it just hands you one more tool, and the responsibility that comes with it.

Le bon unsafe : un cœur minuscule, prouvé une fois, derrière une API sûre.Good unsafe: a tiny core, proven once, behind a safe API.

Si unsafe est si dangereux, pourquoi la std en est-elle truffée ? Parce que c'est exactement ainsi qu'on bâtit une abstraction sûre par-dessus une opération que le compilateur ne sait pas vérifier. Le patron est invariable : un cœur unsafe minuscule, qui maintient un invariant précis, enfermé derrière une API dont la signature est, elle, parfaitement sûre. Prends couper, qui rend deux &mut sur deux moitiés disjointes d'un slice : le borrow checker ne peut pas prouver que les moitiés ne se chevauchent pas, alors on descend aux pointeurs bruts — mais on prouve nous-mêmes la disjonction, une seule fois, avec un commentaire // SAFETY: qui l'explicite. L'appelant, lui, n'écrit jamais unsafe : il reçoit deux références sûres. Tout Vec, tout itérateur du №1, repose là-dessus. C'est aussi le seul moyen de parler au monde extérieur — le C, via extern «C» — qui est unsafe par nature, et qu'on enveloppe de la même façon.If unsafe is so dangerous, why is the std riddled with it? Because that's exactly how you build a safe abstraction over an operation the compiler can't verify. The pattern is invariable: a tiny unsafe core, maintaining a precise invariant, locked behind an API whose signature is perfectly safe. Take couper, returning two &mut over two disjoint halves of a slice: the borrow checker can't prove the halves don't overlap, so you drop to raw pointers — but you prove the disjointness yourself, just once, with a // SAFETY: comment spelling it out. The caller never writes unsafe: they receive two safe references. Every Vec, every iterator from №1, rests on this. It's also the only way to talk to the outside world — C, via extern «C» — which is unsafe by nature, and which you wrap the same way.

use std::slice;

// le compilateur ne PEUT pas prouver que deux &mut visent des moitiés DISJOINTES d'un slice.
// on le prouve nous-mêmes, une fois, dans un cœur unsafe — derrière une API sûre :
fn couper(v: &mut [i32], i: usize) -> (&mut [i32], &mut [i32]) {
    let len = v.len();
    assert!(i <= len);                // l'assert FAIT PARTIE de la preuve : sans lui,
    let p = v.as_mut_ptr();           // un i > len produirait un slice hors bornes → UB
    // SAFETY: l'assert garantit i <= len, donc [0, i) et [i, len) ne se chevauchent pas
    // → deux &mut disjoints.
    unsafe {
        (slice::from_raw_parts_mut(p, i),
         slice::from_raw_parts_mut(p.add(i), len - i))
    }
}
// l'appelant n'écrit JAMAIS unsafe : il reçoit deux &mut sûrs. l'invariant est prouvé ICI, une fois.

// FFI : parler à du C est unsafe par nature — le compilateur ne voit pas l'autre côté
unsafe extern "C" {                  // édition 2024 : le bloc extern est lui-même unsafe
    fn abs(input: i32) -> i32;        // déclaration d'une fonction C
}

pub fn valeur_absolue(x: i32) -> i32 {   // ← API Rust SÛRE exposée au reste du programme
    unsafe { abs(x) }                    // l'appel brut est unsafe ; on l'enveloppe ici
}
// même schéma : un cœur unsafe minuscule, une frontière sûre autour. le reste du code ignore le C.

unsafe pour faire taire le borrow checker — et réintroduire le bug du Vol 1.unsafe to silence the borrow checker — and bring back Vol 1's bug.

Voici le contre-exemple qui clôt la série, et c'est le pire usage d'unsafe : s'en servir pour contourner une erreur de borrow checker qu'on n'a pas comprise. Le scénario est universel. On veut deux &mut sur des éléments d'un même Vec, le compilateur refuse, et plutôt que de se demander pourquoi, on dégaine les pointeurs bruts : un unsafe, deux déréférencements, et ça compile. Sauf qu'on n'a rien résolu — on a déplacé le problème de la compilation vers l'exécution, et repris à sa charge une preuve qu'on est précisément incapable de faire, puisqu'on n'a pas compris l'erreur. Si les deux indices peuvent être égaux, c'est de l'aliasing mutable : exactement l'aliasing mutable que tout le Vol 1 rendait impossible, réintroduite à la main, avec en prime le risque d'UB. Le borrow checker ne dressait pas un mur arbitraire : il posait une question de design. unsafe ne répond pas à la question — il la fait taire.Here's the counter-example that closes the series, and it's the worst use of unsafe: using it to dodge a borrow-checker error you didn't understand. The scenario is universal. You want two &mut on elements of the same Vec, the compiler refuses, and rather than asking why, you draw raw pointers: an unsafe, two dereferences, and it compiles. Except you've solved nothing — you've moved the problem from compile time to runtime, and taken back a proof you're precisely unable to make, since you didn't understand the error. If the two indices can be equal, it's mutable aliasing: exactly the mutable aliasing all of Vol 1 made impossible, reintroduced by hand, with the bonus risk of UB. The borrow checker wasn't raising an arbitrary wall: it was asking a design question. unsafe doesn't answer the question — it silences it.

// ✕ le combat : pousser dans noeuds[i] ET muter noeuds[j]. le borrow checker refuse
//   deux &mut sur le même Vec. au lieu de repenser la possession, on FORCE avec des pointeurs :
let p = noeuds.as_mut_ptr();
unsafe {
    let a = &mut *p.add(i);        // deux &mut sur le même Vec, via pointeurs bruts —
    let b = &mut *p.add(j);        // si i == j, c'est de l'ALIASING MUTABLE → undefined behavior
    a.fils.push(j);
    b.valeur += 1;
}
// on vient de réintroduire, à la main, exactement l'aliasing mutable que tout le Vol 1 rendait IMPOSSIBLE.

// ✓ le refactor de possession : ne jamais tenir deux &mut, agir en deux temps
noeuds[i].fils.push(j);            // un seul &mut à la fois, vérifié à la compilation
noeuds[j].valeur += 1;             // emprunt séparé, séquentiel — aucun chevauchement

// s'il faut vraiment les deux &mut en même temps : noeuds.get_disjoint_mut([i, j])
// rend une Err si i == j — la preuve de disjonction, faite par la std.
// si la structure l'exige vraiment, l'arène du Vol 6 №3 : un Vec + des indices (usize),
// le borrow checker reprend tout son pouvoir. aucun unsafe, aucun risque d'UB.

La version sûre est aussi la plus simple : deux accès séquentiels, chacun avec un seul &mut vérifié. Pas de pointeurs, pas de // SAFETY: à honorer, pas de risque d'UB. Et si la structure réclame vraiment des accès croisés, le Vol 6 №3 avait la réponse : l'arène — un Vec propriétaire, des indices usize en guise de liens — qui rend au borrow checker tout son pouvoir. Une erreur de borrow checker est une question de design, pas un mur à percer. Le bon unsafe sert à faire ce que le langage ne peut pas exprimer — parler au C, bâtir une primitive — jamais à éviter de penser la possession.The safe version is also the simplest: two sequential accesses, each with a single checked &mut. No pointers, no // SAFETY: to honor, no risk of UB. And if the structure genuinely demands crossed accesses, Vol 6 №3 had the answer: the arena — an owning Vec, usize indices as links — which gives the borrow checker back its full power. A borrow-checker error is a design question, not a wall to drill through. Good unsafe serves to do what the language cannot express — talk to C, build a primitive — never to avoid thinking about ownership.