Pour faire vite, tu as plusieurs types de bug. Tu as effectivement les bugs sémantiques et la sauf specifications formelles l'outil ne trouvera j'amais l'erreur. Tu regardes si 42 t'es envoyé alors que c'etait 422 ca marchera pas.
Par contre tu peux facilement detecter des choses qui sont a coup sur des erreurs. Trivialement, ce que fait gcc, si tu utilises une variable non initialisé c'est un bug, une fuite mémoire ca peut se retrouver en analyse statique aussi.
Évidement tu ne trouves pas tout et il faut vérifier ce que te sors l'outil. C'est l'étape plus évolué de ce que te propose gcc ou splint. Bien évidement c'est beaucoup simplifié mais tu trouveras sur la page de danwson engler quelques transparents interessant : http://www.stanford.edu/~engler/(...) . Ca tombe bien c'est le monsieur qui encadrait SWAT a stanford !
> pourquoi c'est pas intégré dans le compilateur directement.
Par ce qu'on peut faire du brouzouf avec et que personne n'a fait quelque chose de si évolué en libre ? :-)
[^] # Re: je comprend pas trop...
Posté par ckyl . En réponse à la dépêche 985 bugs dans le noyau Linux. Évalué à 10.
Par contre tu peux facilement detecter des choses qui sont a coup sur des erreurs. Trivialement, ce que fait gcc, si tu utilises une variable non initialisé c'est un bug, une fuite mémoire ca peut se retrouver en analyse statique aussi.
Évidement tu ne trouves pas tout et il faut vérifier ce que te sors l'outil. C'est l'étape plus évolué de ce que te propose gcc ou splint. Bien évidement c'est beaucoup simplifié mais tu trouveras sur la page de danwson engler quelques transparents interessant : http://www.stanford.edu/~engler/(...) . Ca tombe bien c'est le monsieur qui encadrait SWAT a stanford !
> pourquoi c'est pas intégré dans le compilateur directement.
Par ce qu'on peut faire du brouzouf avec et que personne n'a fait quelque chose de si évolué en libre ? :-)