Revue indépendante de PVS-Studio (Linux, C++)

J'ai vu une publication disant que PVS avait appris à analyser sous Linux, et j'ai décidé d'essayer sur mes projets. Voici ce que cela a donné.

Contenu

1. Avantages
2. Inconvénients
3. Résultats
4. Postface

Avantages

Support réactif

J'ai demandé une clé d'essai, et je l'ai reçue le même jour.

Documentation assez claire

J'ai réussi à lancer l'analyseur sans trop de problèmes. Il y a aussi de l'aide pour les commandes en console (bien qu'il y ait des remarques à ce sujet, voir la section Inconvénients).

Possibilité d'analyse multithread

L'analyseur a une option « standard » -j, permettant d'effectuer l'analyse en parallèle sur plusieurs tâches. Cela fait gagner beaucoup de temps.

Bonne visualisation

De nombreux formats de sortie, du texte à une petite interface web. L'interface web est pratique, concise, avec des suggestions à côté des lignes de code et des liens vers des descriptions des diagnostics..

Intégration facile dans la compilation

Toute la documentation est disponible sur leur site, je dirai juste que si votre projet est compilé avec CMake, c'est très simple.

Bonnes descriptions des diagnostics

Si vous générez la sortie en mode fullhtml, chaque message a un lien vers une description des diagnostics, avec des explications, des exemples de code et des liens supplémentaires.

Inconvénients

Incompréhension de la langue C++ par l'analyseur

Malheureusement, PVS fait parfois des erreurs de syntaxe, générant des messages faux positifs pour un code parfaitement correct.

Par exemple, il y a une fonction qui retourne void:

template <typename T>
auto copy (const void *source, void *destination)
    ->
        std::enable_if_t
        <
            std::is_copy_constructible<T>::value
        >
{
    new (destination) T(*static_cast<const T *>(source));
}

Oui, le mot-clé auto peut signifier void, c'est justement son but. auto. Mais PVS a généré les messages suivants :

dynamic_tuple_management.hpp:29:1: erreur : V591 Fonction non-void doit retourner une valeur.
dynamic_tuple_management.hpp:29:1: erreur : V2542 Fonction avec un type de retour non-void doit retourner une valeur depuis tous les chemins de sortie.

Site très lent

Oui, dans l'interface web, à côté de chaque message, il y a un lien vers la description de diagnostic correspondant avec des exemples. Mais en cliquant sur le lien, il faut attendre assez longtemps, et parfois il y a aussi un 504 Gateway Time-out.

Langue

Toutes les descriptions sont disponibles en russe, c'est excellent. Mais les liens des rapports mènent toujours à la version anglaise. Ce serait bien d'avoir la possibilité de changer de langue pour consulter les diagnostics directement en russe. Je n'ai pas trouvé cette option dans l'interface.

Il est peu pratique de travailler avec les niveaux de diagnostic via la console.

Commençons par le fait que les deux outils utilisés (ce sont pvs-studio-analyzer et plog-converter) ont des formats de spécification de diagnostic différents.

La documentation pour pvs-studio-analyzer indique :

-a [MODE], --analysis-mode [MODE]
    MODE définit le type d'avertissements :
    1 - erreurs 64 bits ;
    2 - réservé ;
    4 - Analyse Générale ;
    8 - Micro-optimisations ;
    16 - Demandes Spécifiques des Clients ;
    32 - MISRA.
    Les modes peuvent être combinés en additionnant les valeurs
    Par défaut : 4

J'ai longtemps essayé de comprendre où il fallait ajouter («adding the values») les clés. J'ai essayé de les énumérer séparées par des virgules :

pvs-studio-analyzer analyze ... -a 1,4,16

J'ai essayé de spécifier la clé plusieurs fois :

pvs-studio-analyzer analyze ... -a 1 -a 4 -a 16

Et ce n'est qu'après que j'ai réalisé qu'il s'agissait de masques binaires ! Il faut donc additionner, pas ajouter les valeurs. Par exemple, pour obtenir des diagnostics globaux, des diagnostics sur les microoptimisations et MISRA, il faut les additionner (4 + 8 + 32 = 44) :

pvs-studio-analyzer analyze ... -a 44

L'utilisation de masques binaires dans les interfaces utilisateur est généralement de mauvais goût. On aurait pu tout additionner en interne et laisser à l'utilisateur un ensemble de cases à cocher.

De plus, il existe un autre utilitaire plog-converter, qui génère des informations lisibles sur l'analyse statique. Il a ses propres particularités.

La documentation du programme plog-converter indique :

-a, --analyzer            Spécifie l'analyseur(s) et le(s) niveau(x) à utiliser pour le filtrage, c'est-à-dire
                          'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
                          Par défaut : GA:1,2

Ici, il y a des niveaux qui n'existaient nulle part auparavant, et je n'ai rien trouvé à leur sujet dans la documentation.

En général, c'est flou. C'est pourquoi j'ai tout réglé au maximum.

Une multitude de messages inutiles sur Catch

Dans deux des trois projets que j'ai analysés, la bibliothèque de tests unitaires Catch2est utilisée. Et une grande partie des messages (!!! 90 sur 138 dans l'un et 297 sur 344 dans l'autre !!!) apparaissent comme suit :

Ne prend pas en compte le multi-threading

Beaucoup de faux positifs concernant des variables prétendument inchangées ou des boucles infinies, alors que ces variables sont manipulées à partir de différents threads, et si ce n'était pas le cas, les tests unitaires échoueraient.

Cependant, un analyseur statique peut-il vraiment considérer cela ? Je ne sais pas.

Résultats

PVS n'a trouvé aucune véritable erreur dans mes projets ouverts Burst et Proxima, ainsi que dans un projet de travail que je ne peux, pour des raisons évidentes, montrer. Cependant, il convient de noter que certains défauts ont déjà été détectés et corrigés auparavant à l'aide de Cppcheck et scan-build.

L'impression générale de tous ces analyseurs est à peu près la même : oui, ils attrapent quelque chose, parfois même quelque chose d'important, mais en gros, un compilateur suffit.

Il se peut (et cela me fait plaisir de le penser) que notre équipe utilise des pratiques de développement logiciel qui permettent de générer un minimum de code de mauvaise qualité. Mieux vaut ne pas créer de problèmes que de les surmonter héroïquement.

C'est pourquoi je me permets de donner quelques conseils sur la manière d'écrire en C++ pour ne pas tirer dans le pied de quelqu'un et ne pas se prendre des coups sur le front.

Utilisez le diagnostic du compilateur au maximum

Notre équipe utilise (et vous conseille) les options de compilation suivantes :

-Werror

-Wall
-Wextra
-Wpedantic

-Wcast-align
-Wcast-qual
-Wconversion
-Wctor-dtor-privacy
-Wenum-compare
-Wfloat-equal
-Wnon-virtual-dtor
-Wold-style-cast
-Woverloaded-virtual
-Wredundant-decls
-Wsign-conversion
-Wsign-promo

Intégrez-les dans votre projet, vous apprendrez beaucoup de nouveau sur votre code.

Respectez la norme

Essayez de ne pas utiliser de choses dépendantes de la plateforme s'il existe des analogues standard, et si vous ne pouvez vraiment pas vous en passer, enveloppez-les dans des blocs spéciaux sous des macros (ou autrement) et ne laissez simplement pas compiler votre code dans des conditions non prises en charge.

Adhérez à la sémantique standard des opérations

L'addition doit être une addition, la multiplication - une multiplication, l'appel de fonction - un appel de fonction, la copie doit copier, le déplacement - déplacer, le conteneur doit être itérable, l'itérateur doit avoir une progression ++ et une déréférencement *. Et ainsi de suite, ainsi de suite.

Je pense que l'idée est claire. Il existe des conventions établies qui ne sont pas obligatoires à respecter, mais que tous les utilisateurs et lecteurs de votre code s'attendent à voir. Ne tentez pas de berner les autres, sinon c'est vous-même que vous bernez.

Écrivez un code compatible

En premier lieu, je pense à la bibliothèque standard. Il est très souhaitable que les interfaces de vos classes et fonctions puissent être utilisées avec les bibliothèques standard et d'autres bibliothèques (par exemple, Boost).

N'hésitez pas à consulter les interfaces STL et Boost. À de rares exceptions près, vous y trouverez un bon exemple à suivre.

Utilisez au maximum les outils ouverts

Pour la même analyse statique, il existe au moins deux outils gratuits et ouverts qui se connectent « en un clic » à tout projet utilisant le système de construction CMake.

Vous pouvez en lire plus dans ma récente publication..

Postface

Enfin, je souligne que je n'encourage pas à ne pas utiliser PVS ou d'autres analyseurs statiques. Mais je vous incite à réfléchir à la raison pour laquelle l'analyseur statique trouve constamment des erreurs significatives dans votre code.

Ceci n'est qu'une conséquence. Il faut chercher et éliminer la cause.

Source : habr.com