Ebauche: Comment avoir une jolie c-enum typesafe en Rust.

src/4_1.md

@@ -0,0 +1,84 @@
+# Recueil de pratiques et motifs de programmation
+
+Cette section a pour objectif de partager des pratiques, motifs et usages
+vu et ici et ailleurs pour resoudre des problemes en Rust.
+
+⚠️ : Attention certains exemples de code pourront utiliser `unsafe` ou nécessiter d'indiquer
+explicitement les invariants que l'appellant ou l'appellée doit maintenir.
+On utilisera le symbole de la bouée ⚠️ pour les reperer.
+
+## Types compatibles avec des enum-C en Rust
+
+En rust nous avons les `enum` qui sont des types dit algebraic. Nous devons par notre code
+convaincre le compilateur rust de l'exaustivité de l'usage de chacun des variants.
+
+C'est extrêmement puissant et utile!
+
+Cependant par exemple dans le monde du Réseau par exemple, l'IETF par consensus va décider
+d'un standard comme le DNS, defini dans des RFC.
+
+Ces RFC vont définir quel format sur le cuivre (les anglosaxons disent "wire format") vont transiter,
+nos paquets réseau et avec quelle forme.
+
+Le DNS par exemple défini dans son format des paquets que les ressource record types dit `QTYPE` sont encodés sur un u16.
+La [RFC 1035](https://datatracker.ietf.org/doc/html/rfc1035#section-3.2.2) historique en definissent certains comme `A = 1`, `SOA = 6`, `NS = 2`.
+
+En C vous pourrez voir le code suivant:
+
+```c
+typedef enum dns_qtype {
+  A = 1,
+  NS = 2,
+  SOA = 6,
+} dns_qtype_t
+```
+Note: parfois c'est des macro preprocesseur C.
+
+En rust nous pourrions être tentés de faire une `enum` ! Mais que-ce-passe t-il si comme
+indiqué par la RFC de nouveaux types peuvent être ajouté? On pourrait ajouter un champ Unknown(u16).
+
+```rust
+#[repr(u16)]
+enum Qtype {
+  A = 1,
+  NS = 2,
+  SOA = 6,
+  // Il a l'air si innocent.
+  Unknown(u16)
+}
+```
+
+Cependant avec cette approche notre type Qtype a cause du variant `Qtype::Unknown(u16)` aura une taille de 
+`4` bytes (un u32) au lieu de 2 bytes (u16)!
+En effet les enums sont compilées actuellement en tagged-unions et il faut un peu de place pour le tag
+qui indique le type! C'est en general absolument pas un probleme sauf parfois dans le cas du réseau et du stockage ou on souhaite
+des types qui suivent le standard au plus proche.
+
+Et bien il existe une solution qui ne nécessite pas de finir avec un bête `u16` et abandonner tout le gain du typage!
+faire un newtype avec des constantes dans l'implementation!
+
+```rust
+struct Qtype(u16)
+
+impl Qtype {
+  const A: Self = Self(1),
+  const NS: Self = Self(2),
+  const SOA: Self = Self(6),
+}
+
+impl From<u16> for QType {
+    fn from(t: c_int) -> QType {
+        Self(t)
+    }
+}
+
+impl From<Qtype> for c_int {
+    fn from(t: Qtype) -> c_int {
+        t.0
+    }
+}
+```
+
+Ce motif est notament utilisé dans `socket2` pour le type `Protocol` !
+
+