Oui, ce type d'outil devrait lever une alerte. Mais le compilateur aussi devrait dire qu'il se passe quelque chose d'étrange.
Mais pour la défense des développeurs, les outils comme coverity, ou certains avertissements du compilateurs, sont difficiles à suivre :
- ils ont tendance à produire des faux négatifs
- les développeurs n'ont pas nécessairement tous les accès aux outils quand ils sont propriétaires (coverity) ou non officiellement supportés (les avertissements de clang diffèrent de ceux de gcc)
- sur le nombre de lignes de code du noyau, il reste beaucoup de rapports à trier
- comment les développeurs pourraient-ils tester ces outils sur leurs dépôts tiers ? A priori coverity ne teste que le noyau 'officiel' de Linus, ils ne peuvent pas savoir avant d'intégrer un commit s'il va augmenter le nombre de rapports. Et même avec un outil d'analyse libre que les devs pourraient lancer eux-même, ces outils sont souvent assez longs, surtout sur une telle base de code...
Pour le coup, je pense que c'est au compilateur de faire un avertissement devant un tel code. Mais il se mettrait sûrement à faire des tas d'avertissements sur par exemple du code généré... Équilibre délicat, je souhaite ne jamais bosser sur un compilateur existant pour ne pas avoir à gérer ce genre de choix entre la peste (ne pas avoir l'avertissement) et le choléra (casser du code existant).
[^] # Re: Petite question technique : un logiciel de vérification n'aurait il pas alerté de cette erreur ?
Posté par Pinaraf . En réponse au journal D'un kernel panic à un patch.... Évalué à 3.
Oui, ce type d'outil devrait lever une alerte. Mais le compilateur aussi devrait dire qu'il se passe quelque chose d'étrange.
Mais pour la défense des développeurs, les outils comme coverity, ou certains avertissements du compilateurs, sont difficiles à suivre :
- ils ont tendance à produire des faux négatifs
- les développeurs n'ont pas nécessairement tous les accès aux outils quand ils sont propriétaires (coverity) ou non officiellement supportés (les avertissements de clang diffèrent de ceux de gcc)
- sur le nombre de lignes de code du noyau, il reste beaucoup de rapports à trier
- comment les développeurs pourraient-ils tester ces outils sur leurs dépôts tiers ? A priori coverity ne teste que le noyau 'officiel' de Linus, ils ne peuvent pas savoir avant d'intégrer un commit s'il va augmenter le nombre de rapports. Et même avec un outil d'analyse libre que les devs pourraient lancer eux-même, ces outils sont souvent assez longs, surtout sur une telle base de code...
Pour le coup, je pense que c'est au compilateur de faire un avertissement devant un tel code. Mais il se mettrait sûrement à faire des tas d'avertissements sur par exemple du code généré... Équilibre délicat, je souhaite ne jamais bosser sur un compilateur existant pour ne pas avoir à gérer ce genre de choix entre la peste (ne pas avoir l'avertissement) et le choléra (casser du code existant).