Vérification statique de code

Bonjour à tous.

Je travaille actuellement dans un projet de robotique et j'écris du code plus ou moins bas niveau.

A divers endroits du code, je manipule des entités qui sont existent physiquement sur ma carte. Par exemple, j'ai un élément qui ne peut être branché que sur les pins 2,3 18, 19, 20 ou 21 de ma carte et pas une autre.

Je souhaiterait automatiser les vérifications pour assurer qu'au moins, le code se base sur des pins "acceptables". Les classes se basant sur des template, je pensais faire un coup de méta prog pour vérifier que l'entier est bien dans un vecteur de boost::mpl mais j'ai 1 souci principal : le poids du code mort. La carte n'a pas de la place illimitée et j'ai peur que ca en mange pour rien. (par ailleurs, j'ai pas essayé boost avec avr-g++, pas sûr que ca passe)

A la suite de cette discussion Je pensais donc me tourner vers un outil entièrement externe. Sauf que là, je sèche : je n'ai pas le moindre nom de logiciel en tête qui soit gratuit et tourne sous linux.

Si vous pouvez éclairer ma lanterne !
Merci.

Salut,

Déjà, normalement, si tu passes par la programmation générique et que tu restreins tes politiques aux seules valeur acceptable, tu devrais pouvoir éviter pas mal de problèmes, pour un code qui, au final, ne devrait pas être particulièrement plus gros, vu que les grosses vérifications se font à la compilation.

Par contre, wikipedia parle de lint sous linux.. L'as tu essayé?

Citation:

---

et que tu restreins tes politiques aux seules valeur acceptable,

---

Effectivement, j'avais oublié qu'un static_assert accepte n'importe quelle expression logique valide :aie:.

Problème résolu

Ceci dit, après avoir lu l'article en question, je ne peux m'empêcher de penser que l'utilisation d'un bon outil d'analyse statique du code ne peut qu'apporter une qualité non négligeable...

Malheureusement, il semble que, encore une fois, linux fasse figure de parent pauvre en terme d'outils efficaces dans le domaine :aie:

Ce qui est, quand on y pense, un comble étant donné le nombre de développements pour lesquels on utilise linux :D.

Enfin, si tu trouves un outil efficace, n'hésites pas à nous en faire part ;)

Je connais pas les outils cités dans l'article, mais cpp check n'est pas un équivalent ?
De plus, sans avoir personnellement fait, je sais qu'il est possible dans cpp check d'ajouter ses propres règles

Bonjour,

Depuis un certains article de Carmack, j'ai fait un peu des recherches.
Pour Linux (gratuit), j'ai trouvé les trois outils suivant :

cppcheck
oink
flawfinder

Malheureusement, je n'ai pas eu le temps de tester tout cela.

Mais, ceci dit, pour rebondir sur

Citation:

---

Envoyé par Davidbrcz

Effectivement, j'avais oublié qu'un static_assert accepte n'importe quelle expression logique valide :aie:.

Problème résolu

---

A vrai dire, je ne pensais même pas au static_assert, mais "juste" à une série de traits correctement étudiés :aie:

Je m'explique... : Tu parles d'éléments qui peuvent être branchés sur les pins 2,3 18, 19, 20 ou 21.

Cela signifie que si tu obtiens quelque chose sur "n'importe quel autre pin" (quel que soit son numéro), tu ne dois pas l'accepter, et que si tu essaye d'accéder à l'état de l'un de ces "n'importe quel autre" pin, il peut sembler correct de refuser la compilation...

Je serais donc parti, assez benoitement, sur quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

/* le template, sans la valeur énumérée, pour toute valeur non prévue*/ template <int > struct PinTrait { }; /* les spécialisations pour 2,3 18, 19, 20 et 21 */ template <int> struct PinTrait<2> { enum{value = 2}; }; template <int> struct PinTrait<3> { enum{value = 3}; }; template <int> struct PinTrait<18> { enum{value = 18}; }; template <int> struct PinTrait<19> { enum{value = 19}; }; template <int> struct PinTrait<20> { enum{value = 20}; }; template <int> struct PinTrait<21> { enum{value = 21}; };

---

avec comme résultat le fait que PinTrait<8>::value; est accepté, alors que PinTrait<XXX>::value (où XXX n'est pas une valeur utilisable) sera refusé à la compilation, même si c'est avec un message relativement cryptique ;)

Encore faut il voir si cela correspond à tes besoins, bien sur ;)

koala01 >> Ca fait trop de classe. Je n'ai que 256Kb de flash. Et mon binaire pèse déjà 15kb.

LittleWhite >> merci pour les liens. Je connaissais Flawfinder et il traque plus des bugs de sécurité.

Cependant, le premier me semble correspondre à ce que je recherche ! A creuser

Salut,
En embarqué, les outils d'analyse de code type lint, Qac ou polyspace, je les ai vu employer pour vérifier des règles de codage (MISRA par expl et +), des règles de 'formattage' (nbr d'espace, retour à la ligne, etc.), mais jamais pour vérifier l'utilisation des bonnes pins.

@david : je ne comprends pas ta dernière remarque. Ces classes ne génèrent pas de code comme en général ce qui relève de la méta-prog?

Pour le support boost/Avr, il semblerait que d'autres aient tenté l'aventure : cf ici

d'apres mes tests, avoir les structs en template ou le nombre directement n'affecte pas la taille du binaire, meme en version debug. Ca affecte la taille des informations de debug mais elles doivent etre strippees pour gagner de la place je pense :)