Pendant un paquet d'années, j'ai programmé en C à titre professionnel (Linux/FreeBSD + GCC).
Je me souviens avoir passé plus d'une demi-journée sur un bug à-la-con. Quand je compilais mon programme avec -O0 (pas d'optimisation), pas de bug. Je compilais avec -O2 (optimisations activées), ça faisait "paf". Et par "paf", je veux dire des comportements passablement aléatoires se concluant le plus souvent sur un crash.
Le programme ne crashait généralement jamais au même endroit ou presque. Aucune erreur qui me sautait aux yeux là où ça crashait. Je m'étais donc résolu à ajouter des traces pour comprendre. La sortie était totalement incohérente.
Après m'être tapé la tête sur le bureau quelque-fois en pleurant, j'ai tenté un truc débile dans le style :
if(1!=1){printf("WTF?!\n");}
... et "WTF?!" est apparu sur l'écran à l’exécution ...
Après une relecture très minutieuse de mon code, j'avais fini par trouver l'erreur : un tableau sur ma pile qui était trop court d'un élément. Du coup, le code allait écrire après le tableau, jardinant joyeusement d'autres trucs au pif sur la pile (c'est ce qu'on appelle un dépassement de pile / stack overflow).
Je n'ai pas cherché plus loin. J'aurais pu essayer de déterminer pourquoi ce dépassement de pile causait tout ce bordel en examinant le code assembleur, mais j'avais clairement d'autres chats à fouetter.
Là où je veux en venir :
Pour rappel, les systèmes d'exploitation et les pilotes de périphériques sont encore quasiment tous codés de nos jours en C ou C++. Or le C (et par extension le C++) est un langage qui demande beaucoup de minutie. Mais l'erreur est humaine. À partir de là, en informatique, plus rien ne me surprend.
# Je blâme le C et le C++
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Le paranormal en informatique. Évalué à 10. Dernière modification le 11 août 2022 à 17:53.
Pendant un paquet d'années, j'ai programmé en C à titre professionnel (Linux/FreeBSD + GCC).
Je me souviens avoir passé plus d'une demi-journée sur un bug à-la-con. Quand je compilais mon programme avec
-O0(pas d'optimisation), pas de bug. Je compilais avec-O2(optimisations activées), ça faisait "paf". Et par "paf", je veux dire des comportements passablement aléatoires se concluant le plus souvent sur un crash.Le programme ne crashait généralement jamais au même endroit ou presque. Aucune erreur qui me sautait aux yeux là où ça crashait. Je m'étais donc résolu à ajouter des traces pour comprendre. La sortie était totalement incohérente.
Après m'être tapé la tête sur le bureau quelque-fois en pleurant, j'ai tenté un truc débile dans le style :
... et "WTF?!" est apparu sur l'écran à l’exécution ...
Après une relecture très minutieuse de mon code, j'avais fini par trouver l'erreur : un tableau sur ma pile qui était trop court d'un élément. Du coup, le code allait écrire après le tableau, jardinant joyeusement d'autres trucs au pif sur la pile (c'est ce qu'on appelle un dépassement de pile / stack overflow).
Je n'ai pas cherché plus loin. J'aurais pu essayer de déterminer pourquoi ce dépassement de pile causait tout ce bordel en examinant le code assembleur, mais j'avais clairement d'autres chats à fouetter.
Là où je veux en venir :
Pour rappel, les systèmes d'exploitation et les pilotes de périphériques sont encore quasiment tous codés de nos jours en C ou C++. Or le C (et par extension le C++) est un langage qui demande beaucoup de minutie. Mais l'erreur est humaine. À partir de là, en informatique, plus rien ne me surprend.