analyseur code pour dépassement mémoire

Bonjour à tous,

j'utilise Splint pour analyser mon code C et je souhaite que le résultat de l'analyse me dise les failles de gestion mémoire du genre (les codes suivants sont triviaux et seulement pour tester les capacités de Splint),:

int *pointeur;
pointeur = malloc(10*sizeof(int));
pointeur[15] = 3;
free(pointeur);

Comme on le sait, ce code passe à la compilation mais provoque des erreurs à l'exécution. C'est pourquoi le mieux est de le détecter avant.

Splint me dit bien qu'il y a une possibilité que pointeur soit NULL, là impécable, je suis d'accords, il faut donc ajouter un if(!NULL) avant d'utiliser le pointeur et Splint ne détecte alors aucun pb de gestion mémoire à cet endroit.

Mais ce que je veux c'est qu'il m'indique que la ligne pointeur[15] = 3; provoque un déppassement, comme il le fait si j'utilise des tableau (dans la vraie vie, on ne trouvera pas, j'espère, une erreur de codage comme ce qui suit ) :

int tableau[10];
tableau[15] = 3;

dans cet exemple, Splint m'indique bien qu'il y a dépassement car 15 est plus grand que 10-1.

J'ai essayé avec des commandes Splint du genre

int *pointeur;
pointeur = malloc(10*sizeof(int));
/*@requires maxSet(pointeur) == 10-1@*/
pointeur[15] = 3;
free(pointeur);

mais Splint ne semble pas comprendre ce que je lui dis.

Quelqu'un à t'il une idée de comment faire ?
Est-ce possible avec Splint ? Sur www.splint.org, ils disent que ca peut ce faire mais ne disent pas comment.
Existe-t-il un analyseur statique qui sache le faire ?

merci à tous !

Très mauvaise habitude de se fier à ce genre de produit.
On n'apprend pas à faire l'infirme si on ne l'est pas.

ciao...
BruNews, MVP VC++

"Comme on le sait, ce code passe à la compilation mais provoque des erreurs à l'exécution. C'est pourquoi le mieux est de le détecter avant".

Je ne vois pas ce qui cloche mis à part que si on l'essaye d'acceder au 15eme int d'un tableau qui en a que 10, cela provoque des segment faults. Pourquoi veux tu utiliser ce logiciel, un cerveau normalement constitué déctecte ce genre de bétises...

"dans cet exemple, Splint m'indique bien qu'il y a dépassement car 15 est plus grand que 10-1", ne crois pas qu'en déclarant un tableau de 10 int tu ne peut en écrire que 9 et OBLIGATOIREMENT laisser le dernier à 0x0, le caractère NULL final c'est simplement une convention pour determiner la fin des chaines de char. Rien ne t'empeche de faire pointeur[9]=0x123;

voilà, @+, vinc1008881

Il y a mieux que "Splint", et cela s'applle "DEBUG" ...
C'est la premiere fois que je vois un logiciel de ce type ! C'est honteux car totalement inutile ! Dans la pluspart des cas on fait pas mallco(10) mais plutot malloc(n) auquel cas "Splint" ne pourra RIEN dire !!!
De plus pourquoi perdre du temps a "analyser" le code au lieu de remonter ses manches et faire du pas-a-pas ... ?!?




Pourquoi faire simple quand on peut faire compliqué ?

Desole pour les accents pas dispo sur ce clavier.

Comme je l'ai indique dans l'introduction de mon 1er message, les codes sont triviaux et ne sont la que pour l'exemple, pour tester Splint avant de le pousser dans ses retranchements. Bien sur que si je code un malloc(10) et que l'instruction suivante est pointeur[15], je suis bon pour aller me coucher ou alors c'est que j'ai bien arrose le repas du midi!!! Maintenant, il est claire que on utilise plutot un malloc(n), ce que test egalement les analyseurs de code.

Je suis tres etonne de vos remarques... entendre dire qu'un analyseur de code c'est honteux :) c'est pareil q'un medecin qui refuse de faire des electrocadiogrammes sous pretexte qu'en ecoutant le coeur battre pendant 2 heures, on arrive au meme diagnostique.

Ca fait 8 ans  que je bosse pour l'aeronautique ou pour l'aerospatiale et ce genre de soft d'analyse statique ou dynamique sont obligatoire pour respecter les normes de securite.En plus, le code est relu par une autre equipe, tout comme la documentation qui est verifiee par 3 personnes differentes avant d'etre validee.

Oui on peut verifier le code a la main, et c'est d'ailleur toujours ce qu'on fait. Bien sur on test en debug, mais tu te vois  tester en debug , a la main, un soft  qui doit gerer  plus de 1000 entrees differentes? Tu peux mais tu mettras combien de temps pour tester toutes les combinaisons ? Et surtout, personne n'est a l'abris de l'erreur humaine!

Je te fais un exemple tres simple pour bien saisir le probleme : tu pense que je vais dire au familles des disparus apres un crash d'avion que je suis desole mais j'avais pourtant teste le soft en debug et que tout passait???

Bref, pour un logiciel maison, on se passe de ce genre d'analyseurs. Pour un soft embarque dans une machine a laver, c'est pas tres grave non plus, a part que je serai tres fache que la machine m'a bouffe toutes mes chaussettes et le codeur se fera surement virer car  ca coutera un max a athur  martin en SAV. Mais pour des applications comme l'aeronautique, ou encore les centrales nucleaire, c'est un autre problemmes, tu me suis ?

En conclusion, pour des logiciels tres complexes ou a risques, les analyseurs de codes sont utilises, tout comme les automates de test de type mercury...

En effet, tester tout les branchments d'un programme en avec un debugger peut etre long, alors qu'avec l'analyse automatique du code on repere tout de suite des erreurs detectable statiquement, seulement ca ne suffit pas.

microsoft utilise ausi ce genre de programme, t'as vu le résultat

Soit c'est un bug de splint (1),
soit c'est l' annotation qui est incorrecte (2;3).

Si en plus du gros programme il faut se préoccupper des bugs de splint juste
pour identifier un buffer overflow, on risque d'atterir à Gonesse avec un peu de retard!
Et un programme sera créé pour contrôler ce que fait splint, et ainsi de suite...

Rien ne remplace une équipe de 10 bons programmeurs, avec 10 approches différentes et
10 bagages d'expériences. Si c'est la vie de centaines de milliers de personnes qui est en jeu,
10 programmeurs ne coutent pas bien cher en terme de masse salariale mais certes,
beaucoup plus que l' achat d'un clavier ou d'une souris.

N'empêche que ça fait pas de mal de rappeler ce type d' erreurs.

1 http://www.splint.org/bugs.html
2 http://www.splint.org/manual/html/sec5.html
3 http://www.splint.org/manual/html/sec9.html

/*@ensures maxSet(pointeur) == (10-1) @*/

L'utilisation d'analyseur de code n'est seulement en dernière vérification pour être un peu plus sur, en espérant être certain :), qu'on a bien éliminé tous les bugs en relecture et en debug. C'est donc une vérification suplémentaire qui permet d'assurer une classe de sécurité plus élevée.
Splint, n'est pas utilisé en aéronautique car il n'offre pas les preuves de sa validation. En gros, il n'est pas validé par une organisation de type ISO et autres.

Je ne sais pas si le problème que je rencontre est dû a un bug de splint, je ne l'ai pas trouvé dans la liste.
J'ai essayé avec /*@ensures maxSet(pointeur) == (10-1) @*/ mais ca ne détecte toujours pas.
J'utilise la commande suivante : splint.exe +bounds buffer.c >essai.txt

Pour Microsoft, c'est un autre débat, oui, ils utilisent des analyseurs statiques, dynamiques, des automates de test... mais je ne pense pas que les codeurs soient si nul que ca, non. Je pencherais plutôt pour dire que premièrement Microsoft doit faire du bénéfice et que les choix marketing, commerciaux et financier ont trop souvent été malheureux, au détriment de la technique.
C'est le fameux triptique coût-durée-technique, tout est lié. Ce genre de considérations n'est pas présent pour linux, en tout cas par rapport au coût, puisque le codeur est "gratuit" et que l'argent que quelques sociétés arrivent à gagner grâce à linux ne se fait uniquement qu'à faveur des services offerts (installation, configuration, formations, développement particuliers...).
En second, et pour sortir du debat windows-linux, dans les secteurs à risque (pour la vie humaine), ont utilisera ni l'un, ni l'autre mais d'autres OS, un peu plus blindés au niveaux de leur validation (et qui peuvent le démontrer sur le papier avec une norme de type ISO ou autre et avec leur expérience).