Les pires bugs ne sont pas ceux qui plantent votre programme. Les pires bugs sont ceux qui produisent silencieusement de mauvais résultats. FLIN avait un tel bug. Deux implémentations séparées du même opcode, vivant dans le même fichier, à 3 418 lignes d'écart, produisant des résultats subtilement différents selon le chemin d'exécution emprunté par la VM.
L'opcode CreateMap -- responsable de la construction de chaque table de hachage dans chaque programme FLIN -- existait sous deux formes. L'une gérait les clés Value::Text. L'autre non. Et pendant des semaines, les maps de traduction perdaient silencieusement des entrées.
La découverte
Le bug est apparu quand les traductions retournaient des clés brutes au lieu de valeurs traduites. La cause réelle : la VM FLIN a deux blocs match séparés pour le dispatch d'opcodes dans execute_until_return() (pour les appels de fonctions) et run() (pour le code de niveau supérieur). La version dans run() ne gérait pas Value::Text, donc quand les clés de map étaient émises comme Value::Text par le compilateur, ces paires clé-valeur étaient silencieusement ignorées.
La correction
rust// La correction : gérer Value::Text
} else if let Value::Text(s) = key {
map.insert(s, value);
}Une ligne de Rust. Trois tokens : else if let. C'était la différence entre des maps de traduction qui fonctionnaient et des maps qui perdaient silencieusement des entrées.
Le problème plus profond : couverture des opcodes
La session 273 a découvert que execute_until_return ne gérait que 35 % de tous les opcodes -- 59 sur 170+. Tout opcode non explicitement géré tombait dans un continue silencieux. Cela signifiait que les boucles for, les requêtes d'entités, les opérations de closures et les manipulations de listes étaient effectivement des no-ops quand exécutées à l'intérieur d'appels de fonctions déclenchés par des interactions utilisateur.
Leçons pour les implémenteurs de langages
- Ne jamais dupliquer les tables de dispatch. Si deux fonctions doivent gérer le même ensemble d'opcodes, elles devraient partager un mécanisme unique de dispatch.
- Le fallthrough silencieux est toujours faux. Une VM de langage devrait soit gérer un opcode, soit produire explicitement une erreur.
- Le choix de représentation de valeur du compilateur ne doit jamais affecter la sémantique.
Ceci est la partie 147 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [146] Auditer 186 000 lignes de code - [147] L'opcode dupliqué qui a failli tout casser (vous êtes ici) - [148] 30 TODO, 5 panics de production, 0 problème de sécurité