Typos

src/en/07_ffi.md

@@ -354,7 +354,7 @@ an `unsafe` block or function.
 > pointer must check their validity beforehand.
 > In particular, pointers must be checked to be non-null before any use.
 >
-> Stronger approaches are advisable when possible. They includes checking
+> Stronger approaches are advisable when possible. They include checking
 > pointers against known valid memory range or tagging (or signing) pointers
 > (particularly applicable if the pointed value is only manipulated from Rust).
 
@@ -648,7 +648,7 @@ impl Drop for Foo {
 
 > ### Warning
 >
-> Because panics may lead to not running the `Drop::drop` method this solution
+> Because panics may lead to not running the `Drop::drop` method, this solution
 > is not sufficient for sensitive deallocation (such as wiping sensitive data)
 > except if the code is guaranteed to never panic.
 >

src/fr/07_ffi.md

@@ -24,7 +24,7 @@ unsafe extern "C" fn mylib_f(param: u32) -> i32 {
 Pour que la fonction `mylib_f` soit accessible avec le même nom, la fonction
 doit être annotée avec l'attribut `#[no_mangle]`).
 
-A l'inverse, il est possible d'appeler des fonctions écrites en C depuis du code
+À l'inverse, il est possible d'appeler des fonctions écrites en C depuis du code
 Rust si celles-ci sont déclarées dans un bloc `extern` :
 
 ```rust
@@ -357,7 +357,7 @@ l'aide Microsoft SAL par exemple.
 >
 > Les exceptions sont :
 >
-> - les références qui sont opaques dans le langage extern et qui sont seulement
+> - les références qui sont opaques dans le langage externe et qui sont seulement
 >   manipulées du côté Rust ;
 > - les références *wrappées* dans un type `Option` (voir note ci-dessous) ;
 > - les références liées à des références sûres dans le langage externe, par
@@ -374,10 +374,10 @@ développement au niveau noyau). Un autre avantage à utiliser les pointeurs Rus
 dans des FFI est que tout chargement de valeur pointée est clairement marqué
 comme appartenant à un bloc ou à une fonction `unsafe`.
 
-> ### Règle {{#check FFI-CKPTR | Vérification des pointeurs externs}}
+> ### Règle {{#check FFI-CKPTR | Vérification des pointeurs externes}}
 >
 > Dans un développement sécurisé en Rust, tout code Rust qui déréférence un
-> pointeur extern doit vérifier leur validité au préalable.
+> pointeur externe doit vérifier leur validité au préalable.
 > En particulier, les pointeurs doivent être vérifiés comme étant non nuls avant
 > toute utilisation.
 >
@@ -387,7 +387,7 @@ comme appartenant à un bloc ou à une fonction `unsafe`.
 > signés, approche particulièrement applicable si la valeur pointée est
 > seulement manipulée depuis le code Rust.
 
-Le code suivant est un simple exemple d'utilisation de pointeur extern dans une
+Le code suivant est un simple exemple d'utilisation de pointeur externe dans une
 fonction Rust exportée :
 
 ```rust,noplaypen
@@ -431,7 +431,7 @@ int main() {
 > est acceptable du côté C. La valeur C `NULL` est comprise par Rust comme la
 > valeur `None`, tandis qu'un pointeur non nul est encapsulé dans le
 > constructeur `Some`. Bien qu'ergonomique, cette fonctionnalité ne permet par
-> contre pas des validations fortes des valeurs de pointeurs comme
+> contre pas de validations fortes des valeurs de pointeurs comme
 > l'appartenance à une plage d'adresse mémoire valide.
 
 #### Pointeurs de fonction
@@ -619,7 +619,7 @@ En fait, il est même recommandé de n'utiliser que des types qui implémentent
 `Copy`. Il faut noter que `*const T` est `Copy` même si `T` ne l'est pas.
 
 Si ne pas récupérer la mémoire et les ressources est mauvais, en termes de
-sécurité, utiliser de la mémoire récupérée plus d'une fois ou libérer deux fois
+sécurité, utiliser de la mémoire déjà libérée ou libérer deux fois
 certaines ressources peut être pire. Afin de libérer correctement une ressource
 une seule et unique fois, il faut savoir quel langage est responsable de la
 gestion de son allocation et de sa libération.
@@ -632,14 +632,14 @@ gestion de son allocation et de sa libération.
 > - un seul langage est responsable de l'allocation et de la libération d'une
 >   donnée ;
 > - l'autre langage ne doit ni allouer, ni libérer la donnée directement, mais
->   peut utiliser une fonction extern dédée fournie par le langage responsable
+>   peut utiliser une fonction externe dédiée fournie par le langage responsable
 >   choisie.
 
 L'identification d'un langage responsable de la gestion des données en mémoire
 ne suffit pas. Il reste à s'assurer de la durée de vie correcte de ces données,
 principalement de s'assurer qu'elles ne sont plus utilisées après leur
 libération. C'est une étape bien plus difficile. Lorsque le langage externe est
-responsable de la mémoire, la même approche est de fournir un *wrapper* sûr
+responsable de la mémoire, la meilleure approche est de fournir un *wrapper* sûr
 autour du type externe.
 
 > ### Recommandation {{#check FFI-MEM-WRAPPING | Encapsulation des données externes dans un type `Drop`}}
@@ -661,7 +661,7 @@ struct RawFoo {
     _private: [u8; 0],
 }
 
-/// API C privée "raw"
+/// API C privée "brut"
 extern "C" {
     fn foo_create() -> *mut RawFoo;
     fn foo_do_something(this: *const RawFoo);