Comportement indéfini (Undefined Behavior, UB) — c'est une situation où la norme du langage ne définit pas le comportement du programme. Le compilateur peut faire ce qu'il veut avec le programme : le programme peut planter, produire un résultat incorrect ou même 'fonctionner'. L'UB survient à cause d'erreurs comme le dépassement de tableau, la déréférence d'un pointeur nul, etc.
int arr[5]; arr[10] = 42; // UB : dépassement de tableau int* p = nullptr; *p = 1; // UB : déréférence 0
Éviter l'UB est possible en respectant les normes, en utilisant des outils modernes (ASan, UBSan, valgrind), en essayant de ne pas utiliser de pointeurs bruts et en écrivant du code sécurisé.
Si l'UB s'est produit dans une partie du programme, cela peut-il affecter une autre partie du code 'indépendante' ?
Oui ! Lors de l'optimisation, le compilateur peut faire des transformations inattendues s'il découvre qu'un UB s'est produit.
void foo(int* p) { if (p == nullptr) return; *p = 5; // Et si p n'était pas nullptr, c'est de l'UB ! Mais le compilateur peut supprimer les vérifications, considérant que p est toujours valide. }
Histoire
Sur le serveur d'une grande entreprise, à cause de la déréférence d'un pointeur nul, des plantages aléatoires se produisaient de temps en temps, difficiles à reproduire : en mode debug, tout fonctionnait, mais en mode release — non.
Histoire
Lors du portage du code de 32 bits à 64 bits, les types de données ont été inversés, utilisant un cast entre int et pointeur. Cela fonctionnait sur certaines machines, tandis que d'autres subissaient des crashs et des artefacts étranges.
Histoire
Un cas célèbre sur Internet a montré comment un UB apparemment inoffensif (dépassement de tableau) a pu casser le fonctionnement de tout le programme : le compilateur avait supprimé non seulement les opérations sur le tableau, mais avait aussi 'optimisé' une partie du code sans lien avec l'erreur.