J'ai envie de dire oui. Ca dépend de ce que l'on attend, évidemment, mais par rapport à ce qu'ils sont censé tester, oui, ils font ce que l'on attend d'eux. Il ne faut pas s'attendre à ce qu'ils disent "ton algorithme est faux parce que tu fait C = a*b alors que la spec demande C = a+b", parce que ce n'est pas leur rôle. Par contre leur rôle c'est de trouver/prouver* des défauts/bugs dans l'utilisation du langage. Par exemple, en C, un analyseur doit (devrait) trouver l'utilisation d'un pointeur ou d'une variable non initialisée, un accès hors limite de tableau, une division par 0, ...
En général, vu que c'est "gratuit" à implémenter, il y a souvent en plus la possibilité de vérifier des bonnes pratiques de codages (par exemple les règles MISRA), mais ça ça peut déjà souvent être fait (en partie au moins) par un linteur (enfin, techniquement, un linteur c'est déjà un outil d'analyse statique)
Comment ça s'appelle ?
Ceux qui sont vendu par ma boite c'est Polyspace Code Prover et Bug Finder.
Combien ça coute ?
Disons qu'on ne vise pas le marché des particuliers ;-) . C'est plutôt à destination des gens qui ont a certifier un produit, souvent dans un processus encadré par des normes (DO-178C, IEC61508, ISO26262, ...) mais pas uniquement. (une autre façon de dire ça serait de dire que parmi les différents trucs qu'on vend, il me semble que ça fait partie des quelque exceptions pour lesquels on n'a pas directement un prix affiché sur le site, mais un lien "contacter un commercial")
Après le prix, dans l'absolu, c'est pas le plus important, la question est "est-ce que ça rapporte plus que ça ne coûte ?" (oh mon dieu, je pense que je traîne trop avec des commerciaux)
* trouver et prouver sont deux termes qui ne veulent pas dire la même chose et qui recouvrent deux types d'outils d'analyse statiques différents. Les outils qui prouvent (par calcul formel, "sound static analyzer" vs "unsound" pour les termes anglais) sont "mieux" (pas de faux positifs, pas de faux négatifs, uniquement des preuves d'absence ou de présence de bug. Ah, et aussi parfois des "je ne sais pas", mais c'est "limité" en nombre). Mais ils sont plus limités par la taille du programme analysé et le type de bugs à identifier. (le temps et la mémoire utilisée pour l'analyse augmente rapidement avec la taille du programme analysé)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: tester c'est douter, mais testez !
Posté par 2PetitsVerres (Mastodon) . En réponse au journal Faites des tests !. Évalué à 6.
J'ai envie de dire oui. Ca dépend de ce que l'on attend, évidemment, mais par rapport à ce qu'ils sont censé tester, oui, ils font ce que l'on attend d'eux. Il ne faut pas s'attendre à ce qu'ils disent "ton algorithme est faux parce que tu fait C = a*b alors que la spec demande C = a+b", parce que ce n'est pas leur rôle. Par contre leur rôle c'est de trouver/prouver* des défauts/bugs dans l'utilisation du langage. Par exemple, en C, un analyseur doit (devrait) trouver l'utilisation d'un pointeur ou d'une variable non initialisée, un accès hors limite de tableau, une division par 0, ...
En général, vu que c'est "gratuit" à implémenter, il y a souvent en plus la possibilité de vérifier des bonnes pratiques de codages (par exemple les règles MISRA), mais ça ça peut déjà souvent être fait (en partie au moins) par un linteur (enfin, techniquement, un linteur c'est déjà un outil d'analyse statique)
Ceux qui sont vendu par ma boite c'est Polyspace Code Prover et Bug Finder.
Disons qu'on ne vise pas le marché des particuliers ;-) . C'est plutôt à destination des gens qui ont a certifier un produit, souvent dans un processus encadré par des normes (DO-178C, IEC61508, ISO26262, ...) mais pas uniquement. (une autre façon de dire ça serait de dire que parmi les différents trucs qu'on vend, il me semble que ça fait partie des quelque exceptions pour lesquels on n'a pas directement un prix affiché sur le site, mais un lien "contacter un commercial")
Après le prix, dans l'absolu, c'est pas le plus important, la question est "est-ce que ça rapporte plus que ça ne coûte ?" (oh mon dieu, je pense que je traîne trop avec des commerciaux)
* trouver et prouver sont deux termes qui ne veulent pas dire la même chose et qui recouvrent deux types d'outils d'analyse statiques différents. Les outils qui prouvent (par calcul formel, "sound static analyzer" vs "unsound" pour les termes anglais) sont "mieux" (pas de faux positifs, pas de faux négatifs, uniquement des preuves d'absence ou de présence de bug. Ah, et aussi parfois des "je ne sais pas", mais c'est "limité" en nombre). Mais ils sont plus limités par la taille du programme analysé et le type de bugs à identifier. (le temps et la mémoire utilisée pour l'analyse augmente rapidement avec la taille du programme analysé)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.