Comment vérifier rapidement les avertissements intéressants donnés par l'analyseur PVS-Studio pour le code C et C ++?


De temps en temps, les programmeurs qui commencent à se familiariser avec l'analyseur de code PVS-Studio me demandent: "Existe-t-il une liste d'avertissements qui indiquent avec précision les erreurs?" Il n'y a pas une telle liste car les avertissements (faux) inintéressants dans un projet sont très importants et utiles dans un autre. Cependant, on peut certainement commencer à creuser dans l'analyseur à partir des avertissements les plus excitants. Examinons de plus près ce sujet.

Le problème est, en règle générale, que le programmeur s'exécute d'abord dans un grand nombre d'avertissements qu'il reçoit. Naturellement, il veut commencer à passer en revue les avertissements les plus intéressants afin de comprendre s'il doit passer son temps à régler tout cela. Bon, voici donc trois étapes simples qui lui permettront de consulter les avertissements les plus excitants.

Étape 1





Désactivez tous les types d'avertissements, à l'exception des avertissements généraux (GA). Une erreur courante consiste à activer tous les types d'avertissements. Les utilisateurs inexpérimentés pensent que plus il faut activer, mieux c'est. Ce n'est pas le cas. Il existe des ensembles de diagnostic, tels que les contrôles 64 bits et les règles MISRA, qui ne doivent être utilisés que lorsque l'on sait clairement de quoi il s'agit et comment les utiliser. Par exemple, en activant les diagnostics MISRA pour un programme d'application ordinaire, vous vous noyerez dans des dizaines, des milliers ou des centaines de milliers d'avertissements tels que:
  • V2506 . Misra. Une fonction doit avoir un seul point de sortie à la fin.
  • V2507 . Misra. Le corps d'une instruction loop \ conditional doit être placé entre accolades.
  • V2523 . Misra. Toutes les constantes entières de type non signé doivent avoir le suffixe «u» ou «U».

La plupart des avertissements MISRA n'indiquent pas des erreurs, mais des odeurs de code. Naturellement, un programmeur commence à poser des questions. Comment trouvez-vous quelque chose d'intéressant dans la pile de tous ces avertissements? Quels numéros doit-il regarder? Ce ne sont pas les bonnes questions. Il vous suffit de désactiver l'ensemble MISRA. Il s'agit de la norme pour écrire du code de qualité pour les appareils intégrés. Le but de la norme est de rendre le code extrêmement simple et compréhensible. N'essayez pas de l'appliquer là où c'est inapproprié.

Remarque Oui, MISRA a des règles conçues pour identifier les vrais bugs. Exemple: V2538 - La valeur de la variable non initialisée ne doit pas être utilisée. Mais n'ayez pas peur de désactiver la norme MISRA. Tu ne vas rien perdre. Les vraies erreurs seront toujours trouvées dans le cadre des diagnostics généraux (GA). Par exemple, une variable non initialisée sera trouvée par le diagnostic V614 .

Étape 2





Tout analyseur statique émet des faux positifs lors des premières exécutions et nécessite une configuration. On ne peut rien y faire, mais ce n'est pas aussi effrayant que cela puisse paraître. Même un simple réglage rapide vous permet de supprimer la plupart des faux positifs et de commencer à afficher un rapport assez pertinent. Je n'en parlerai pas plus, comme je l'ai écrit à plusieurs reprises, par exemple, dans cet article: " Caractéristiques de PVS-Studio Analyzer par l'exemple des bibliothèques de base EFL, 10-15% de faux positifs ".

Passez un peu de temps à désactiver les avertissements manifestement non pertinents et à lutter contre les faux positifs liés aux macros. De manière générale, les macros sont la principale raison des faux positifs, car un avertissement apparaît dans tous les cas lorsqu'une macro mal implémentée est utilisée. Pour supprimer les avertissements dans les macros, vous pouvez écrire des commentaires d'un type spécial à côté de leur déclaration. Le plus de format de commentaires est couvert dans la documentation .

Oui, le réglage initial prendra un peu de temps, mais améliorera considérablement la perception du rapport en éliminant le bruit gênant. Prenez le temps de le faire. S'il y a des difficultés ou des questions, nous sommes toujours prêts à vous aider et à vous dire comment configurer l'analyseur de la meilleure façon. N'hésitez pas à nous écrire et à nous poser des questions.

Étape 3





Commencez à afficher les avertissements à partir du niveau 1. Seulement après avoir regardé les niveaux 2 et 3. Les niveaux d'avertissement ne sont rien de plus que la véracité d'un avertissement. Les avertissements du niveau 1 sont plus susceptibles d'indiquer une erreur réelle que les avertissements du niveau 2.

Vous pouvez dire que lorsque vous choisissez de "regarder le niveau 1", vous appuyez sur le bouton "regarder les erreurs les plus intéressantes".

Plus en détail, la classification des avertissements de PVS-Studio par niveaux est décrite dans l'article " La façon dont les analyseurs statiques luttent contre les faux positifs, et pourquoi ils le font ".

Alors pourquoi n'y a-t-il pas de liste?





Cependant, l'idée d'avoir une liste des avertissements les plus utiles peut encore sembler raisonnable. Permettez-moi de vous montrer dans un exemple pratique que l'utilité d'un diagnostic est relative et dépend du projet.

Prenons l'avertissement V550 . L'avertissement détecte une erreur potentielle liée au fait que pour comparer des nombres avec une virgule flottante, les opérateurs == ou! = Sont utilisés.

La plupart des développeurs à qui j'ai parlé pensent que ce diagnostic est inutile et ils le désactivent car tous ses déclenchements pour leur projet sont faux. C'est pourquoi ce diagnostic a un faible niveau de certitude et se rapporte au niveau 3.

En effet, dans la plupart des applications, les types float / double sont utilisés dans des algorithmes très simples. Souvent, la comparaison avec la constante sert uniquement à vérifier si une certaine valeur est définie par défaut ou si elle a changé. Dans ce cas, la vérification exacte est tout à fait appropriée. Je vais l'expliquer avec un pseudo-code.

float value = 1.0f; if (IsUserInputNewValue()) value = GetUserValue(); if (value == 1.0f) DefaultBehavior(); else Foo(value); 

Ici, la comparaison (valeur de 1.0f) est correcte et sûre.

Est-ce à dire que le diagnostic V550 est sans intérêt? Non. Tout dépend du projet. Permettez-moi de citer un extrait de l'article " Comment nous avons essayé l'analyse statique sur notre projet de simulateur de formation en chirurgie endovasculaire aux rayons X ", rédigé par notre utilisateur.

Alors, à quoi notre analyseur statique fait attention ici:

V550 Une comparaison étrange et précise: t! = 0. Il est probablement préférable d'utiliser une comparaison avec une précision définie: fabs (A - B)> Epsilon. objectextractpart.cpp 3401

 D3DXVECTOR3 N = VectorMultiplication( VectorMultiplication(V-VP, VN), VN); float t = Qsqrt(Scalar(N, N)); if (t!=0) { N/=t; V = V - N * DistPointToSurface(V, VP, N); } 

Des erreurs de ce type se répètent assez souvent dans cette bibliothèque. Je ne peux pas dire que cela m’a surpris. Auparavant, j'ai rencontré une gestion incorrecte des nombres avec une virgule flottante dans ce projet. Cependant, il n'y avait pas de ressources pour vérifier systématiquement les sources. À la suite de la vérification, il est devenu clair qu'il était nécessaire de donner au développeur quelque chose pour élargir ses horizons en termes de travail avec des nombres à virgule flottante. Il a été lié à quelques bons articles. Nous verrons comment les choses se passeront. Il est difficile de dire avec certitude si cette erreur provoque de véritables perturbations dans le programme. La solution actuelle expose un certain nombre d'exigences pour le maillage polygonal d'origine des artères, qui simule la propagation de la matière de contraste aux rayons X. Si les exigences ne sont pas remplies, le programme peut tomber ou le travail est clairement incorrect. Certaines de ces exigences sont obtenues analytiquement, et d'autres - empiriquement. Il est possible que cet ensemble empirique d'exigences croisse simplement en raison d'une mauvaise gestion des nombres à virgule flottante. Il convient de noter que tous les cas trouvés d'utilisation d'une comparaison précise des nombres avec une virgule flottante n'étaient pas une erreur.

Comme vous pouvez le voir, ce qui n'est pas intéressant dans certains projets intéresse d'autres. Il est donc impossible de créer une liste des "plus intéressants".

Remarque Vous pouvez également définir le niveau des avertissements à l'aide des paramètres. Par exemple, si vous pensez que le diagnostic du V550 mérite une attention particulière, vous pouvez le déplacer du niveau 3 au niveau 1. Ce type de paramètres est décrit dans la documentation (voir «Comment définir votre niveau pour des diagnostics spécifiques»).

Conclusion



Vous savez maintenant comment commencer à étudier les avertissements de l'analyseur en examinant les plus intéressants. Et n'oubliez pas de consulter la documentation pour obtenir une description détaillée des avertissements. Parfois, il arrive que derrière un non-descriptif, à première vue, l'avertissement se trouve l'enfer. Un exemple de tels diagnostics: V597 , V1026 . Merci de votre attention.

Source: https://habr.com/ru/post/fr457330/


All Articles