Détection de code mort dans un projet C/C++ existant

Question

Comment procéder pour détecter un code mort dans un code C/C++ ? J'ai une base de code assez importante avec laquelle je travaille et au moins 10-15% est du code mort. Existe-t-il un outil basé sur Unix pour identifier ces zones ? Certains morceaux de code utilisent encore beaucoup de préprocesseur, un processus automatisé peut-il gérer cela ?

Answer 1

Pour cela, vous pouvez utiliser un outil d'analyse de la couverture du code et rechercher les endroits inutilisés dans votre code.

Un outil populaire pour la chaîne d'outils gcc est gcov, ainsi que le frontal graphique lcov ( http://ltp.sourceforge.net/coverage/lcov.php ).

Si vous utilisez gcc, vous pouvez compiler avec le support de gcov, qui est activé par l'option '--coverage'. Ensuite, exécutez votre application ou votre suite de tests avec cette compilation activée par gcov.

En fait, gcc émet des fichiers supplémentaires pendant la compilation et l'application émet également des données de couverture pendant son exécution. Vous devez collecter tous ces fichiers (fichiers .gcdo et .gcda). Je ne vais pas entrer dans tous les détails ici, mais vous devez probablement définir deux variables d'environnement pour collecter les données de couverture de manière saine : GCOV_PREFIX et GCOV_PREFIX_STRIP...

Après l'exécution, vous pouvez rassembler toutes les données de couverture et les exécuter avec la suite d'outils lcov. La fusion de tous les fichiers de couverture de différents tests est également possible, bien qu'un peu complexe.

Quoi qu'il en soit, vous vous retrouvez avec un bel ensemble de pages web montrant des informations sur la couverture, en indiquant les morceaux de code qui n'ont pas de couverture et qui n'ont donc pas été utilisés.

Bien sûr, vous devez vérifier que les portions de code ne sont pas utilisées dans n'importe quelle situation et cela dépend beaucoup de la qualité des tests effectués sur la base de code. Mais au moins, cela donnera une idée des candidats possibles au code mort...

Answer 2

Compilez-le sous gcc avec -Wunreachable-code.

Je pense que plus la version est récente, plus vous obtiendrez de bons résultats, mais je peux me tromper en pensant que c'est un sujet sur lequel ils travaillent activement. Notez qu'il fait une analyse de flux, mais je ne crois pas qu'il vous parle du "code" qui est déjà mort au moment où il quitte le préprocesseur, car il n'est jamais analysé par le compilateur. Il ne détectera pas non plus, par exemple, les fonctions exportées qui ne sont jamais appelées, ou le code de gestion des cas spéciaux qui se trouve être impossible parce que rien n'appelle jamais la fonction avec ce paramètre - vous avez besoin de couverture de code pour cela (et exécutez les tests fonctionnels, pas les tests unitaires. Les tests unitaires sont supposée pour avoir une couverture de code de 100%, et donc exécuter des chemins de code qui sont "morts" en ce qui concerne l'application). Néanmoins, avec ces limitations à l'esprit, il s'agit d'un moyen facile de commencer à trouver les routines les plus abîmées dans le code de base.

Cet avis du CERT énumère d'autres outils pour la détection statique de code mort.

Answer 3

Votre approche dépend de la disponibilité des tests (automatisés). Si vous disposez d'une suite de tests dont vous êtes sûr qu'elle couvre une quantité suffisante de fonctionnalités, vous pouvez utiliser une analyse de couverture, comme les réponses précédentes l'ont déjà suggéré.

Si vous n'avez pas cette chance, vous pouvez vous tourner vers des outils d'analyse du code source tels que SciTools Comprendre qui peut vous aider à analyser votre code en utilisant un grand nombre de rapports d'analyse intégrés. Mon expérience avec cet outil date d'il y a deux ans, je ne peux donc pas vous donner beaucoup de détails, mais ce dont je me souviens, c'est qu'ils avaient un support impressionnant avec des délais d'exécution très rapides pour les corrections de bugs et les réponses aux questions.

J'ai trouvé une page sur analyse statique du code source qui répertorie également de nombreux autres outils.

Si cela ne vous aide pas suffisamment non plus, et que vous êtes spécifiquement intéressé à trouver le code mort lié au préprocesseur, je vous recommanderais de poster quelques détails supplémentaires sur le code. Par exemple, s'il est principalement lié à diverses combinaisons de paramètres #ifdef, vous pourriez écrire des scripts pour déterminer les (combinaisons de) paramètres et trouver quelles combinaisons ne sont jamais construites, etc.

Answer 4

Les deux sites Mozilla et Bureau ouvert ont des solutions maison.

Answer 5

Pour le code C uniquement et en supposant que le code source de l'ensemble du projet est disponible, lancez une analyse avec l'outil Open Source Frama-C . Toute déclaration du programme qui affiche du rouge dans l'interface graphique est code mort.

Si vous avez des problèmes de "code mort", vous pouvez également être intéressé par les points suivants supprimer le "code de réserve", c'est-à-dire le code qui est exécuté mais qui ne mais qui ne contribue pas au résultat final. Pour ce faire, vous devez fournir une modélisation précise des fonctions E/S (vous ne voudriez pas supprimer un calcul qui semble être "de rechange" mais qui qui est utilisé comme argument pour printf ). Frama-C dispose d'une option permettant de signaler le code de réserve.