Qu'on me corrige si je me trompe mais pour moi cet outil ce rapproche plus de frama-C que de cppcheck.
De souvenir avec Frama-C il fallait écrire du code pour l'analyse de source. Mais enfin c'était peut-être pour des fonctions de "couverture de code".
Pour de l'embarqué (monde des uC) c'est toujours compliqué vu que l'on a des dépendances sur le matériel, et que l'outil qui s'exécute sur le PC ne peut réaliser une analyse complète (j'ai vu que ces analyseurs compilait le code).
Pour moi l'intérêt serait confirmé si l'outil pouvait répondre la conformité du code par rapport à la norme MISRA-C. Et forcément ça demande plus que de la détection de bug/faille.
On ajoutera à ça le besoin d'avoir des métriques "personnalisées" dans les métriques.
Pour un client j'avais utilisé OClint :
- analyse statique basée sur LLVM
- système d'intégration de métriques personnalisée sous la forme d'un fichier de conf et de DLL permettant de vérifier la convention de nommage et autres regles basées sur des regex permettant d'analyser l'AST généré ou le nombre cyclomatique d'une fonction.
- à ça vous ajoutez la génération d'un rapport type tableur pour toutes les anomalies, que l'on pouvait trier par niveau de gravité.
Pour l'analyse statique, comme il fallait compiler les fichiers que l'on avait un projet type 'Makefile générique', on a utilisé bear pour générer une base JSON de compilation de fichiers individuel (que sait générer cmake).
Ca marchait très bien sous Linux x86.
Mais voilà pour de l'embarqué uC ca perd de sa saveur car la compilation n'est plus possible à moins d'avoir un LLVM configuré pour la cible ou un code source instrumenté pour permette une analyse partielle.
On doit avoir le même pb avec cet outil non ?
# intérêt de l'outil limité pour de l'embarqué.
Posté par Selso (site web personnel) . En réponse au journal IKOS, un analyseur statique développé à la NASA. Évalué à 1.
Qu'on me corrige si je me trompe mais pour moi cet outil ce rapproche plus de frama-C que de cppcheck.
De souvenir avec Frama-C il fallait écrire du code pour l'analyse de source. Mais enfin c'était peut-être pour des fonctions de "couverture de code".
Pour de l'embarqué (monde des uC) c'est toujours compliqué vu que l'on a des dépendances sur le matériel, et que l'outil qui s'exécute sur le PC ne peut réaliser une analyse complète (j'ai vu que ces analyseurs compilait le code).
Pour moi l'intérêt serait confirmé si l'outil pouvait répondre la conformité du code par rapport à la norme MISRA-C. Et forcément ça demande plus que de la détection de bug/faille.
On ajoutera à ça le besoin d'avoir des métriques "personnalisées" dans les métriques.
Pour un client j'avais utilisé OClint :
- analyse statique basée sur LLVM
- système d'intégration de métriques personnalisée sous la forme d'un fichier de conf et de DLL permettant de vérifier la convention de nommage et autres regles basées sur des regex permettant d'analyser l'AST généré ou le nombre cyclomatique d'une fonction.
- à ça vous ajoutez la génération d'un rapport type tableur pour toutes les anomalies, que l'on pouvait trier par niveau de gravité.
Pour l'analyse statique, comme il fallait compiler les fichiers que l'on avait un projet type 'Makefile générique', on a utilisé bear pour générer une base JSON de compilation de fichiers individuel (que sait générer cmake).
Ca marchait très bien sous Linux x86.
Mais voilà pour de l'embarqué uC ca perd de sa saveur car la compilation n'est plus possible à moins d'avoir un LLVM configuré pour la cible ou un code source instrumenté pour permette une analyse partielle.
On doit avoir le même pb avec cet outil non ?