La présence de GOTOs qui pointent vers un et un seul label pour le traitement d'erreurs et seulement dans ce cas, au sein d'une fonction C complexe est une pratique admise et correcte.
Bjarne Stroustrup, qui aime bien donner des conseils de programmation en C++ l'explique dans son livre The C++ Language, pour justifier pourquoi il a gardé le goto de C dans C++ (outre la question de la compatibilité avec le C, bien sûr)
Le chiffre en clair ne devrait pas être là, c'est sûr, ainsi que d'autres l'ont relevé dans leurs commentaires. Mais ce n'est pas le sujet.
Sans vouloir me faire l'avocat du diable, car à mon humble avis Linus Torvalds devrait corriger ses mauvaises pratiques du langage humain :-), ce qu'il veut surtout dire dans son post sur LKLM c'est que le code incriminé est difficile à relire, à comprendre et donc à maintenir, avec risque d'introduction de bugs. Sur ce point il me semble qu'il a raison. Dans le cas présent, que le code soit plus général ne me semble pas un avantage.
La présence de GOTOs qui pointent vers un et un seul label pour le traitement d'erreurs et seulement dans ce cas, au sein d'une fonction C complexe est une pratique admise et correcte.
Bjarne Stroustrup, qui aime bien donner des conseils de programmation en C++ l'explique dans son livre The C++ Language, pour justifier pourquoi il a gardé le goto de C dans C++ (outre la question de la compatibilité avec le C, bien sûr)
Le chiffre en clair ne devrait pas être là, c'est sûr, ainsi que d'autres l'ont relevé dans leurs commentaires. Mais ce n'est pas le sujet.
Sans vouloir me faire l'avocat du diable, car à mon humble avis Linus Torvalds devrait corriger ses mauvaises pratiques du langage humain :-), ce qu'il veut surtout dire dans son post sur LKLM c'est que le code incriminé est difficile à relire, à comprendre et donc à maintenir, avec risque d'introduction de bugs. Sur ce point il me semble qu'il a raison. Dans le cas présent, que le code soit plus général ne me semble pas un avantage.