Articles précédents : Articles
- [49] Le premier téléphone portable sous Linux en France.
- [1] L'INJEP favorise les logiciels libres
- [15] Fosdem 2005 : la liste des orateurs est là !
- [21] Paru dans Le Monde : La liberté de choix des logiciels, enjeu politique
- [14] changements sur LinuxFocus
- [319] Brevets logiciels : nouvelle offensive surprise
- [17] Hispalinux en justice contre la sécurité sociale
- [161] p2p: premières résiliations d'abonnements
- [16] Pétition pour soutenir le développement de logiciels libres pour l'éducation
- [24] Novell et Netline annoncent Open Exchange en Open Source
Liens connexes
- Article de LWN sur l'annonce initiale (1261 hits)
- Graphiques des bugs de Linux (2406 hits)
- Le site de l'analyseur SWAT (1410 hits)
- Les commentaires sur OSNews (951 hits)
- Un article sur SPARSE (939 hits)
Dépêche modérée par
Dépêche éditée par
Articles : 985 bugs dans le noyau Linux
Posté par patrick_g (page perso, ). Modéré le 16 décembre 2004.
La majorité des bugs se trouve dans les modules des pilotes et seulement 1% dans le c½ur du noyau.
Le ratio est donc d'environ 0.17 bugs par millier de lignes ce qui, selon l'université Carnegie Mellon, est beaucoup moins que les logiciels classiques.
En effet il n'est pas rare d'observer, dans ces logiciels, un ratio de 20 à 30 bugs par millier de lignes ce qui se traduirait par un total compris entre 114.000 et 171.000 bugs sur un projet de la taille de Linux.
Voici un total récapitulatif des bugs considérés comme critiques du noyau :
* Défauts causant un crash système : 569
* Dépassement de tampon mémoire : 25
* Fuite mémoire : 33
* Problème de sécurité : 100
![[en]](../../../images/en.png)
Article de LWN sur l'annonce initiale (1261 hits)-
Graphiques des bugs de Linux (2406 hits)
-
Le site de l'analyseur SWAT (1410 hits)
-
Les commentaires sur OSNews (951 hits)
-
Un article sur SPARSE (939 hits)
> Lire la suite (108 commentaires, moyenne: 3,7). [dépêche : 2035 caractères]
En premier lieu il semble que cet analyseur de code est juste une version commerciale (NdM : propriétaire) du logiciel "Stanford Checker" déjà connu et que la société Coverity est une start-up fondée pour vendre ce logiciel. Pour assurer sa promotion elle offre librement aux développeurs Linux le résultat de ses investigations. Il semble donc nécessaire de garder à l'esprit son souci de publicité.
Ensuite les ratios donnés par l'université Carnegie Mellon semblent étranges à beaucoup de commentateurs qui soulignent que les logiciels traditionnels ont plus probablement entre 1 et 5 bugs par millier de lignes de code (le chiffre de 2 pour Windows2000 a été avancé... sachant que ce système complet est bien plus gros qu'un simple noyau).
Enfin il faut bien voir que ce total de 985 bugs est un chiffre absolument minimum qui omet toutes les erreurs existantes dans le noyau mais passant, pour une raison ou pour une autre, à travers les mailles de SWAT.
Malgré tout cette annonce est bénéfique pour le projet Linux puisqu'elle va permettre de corriger des erreurs et qu'elle souligne la bonne qualité du noyau actuel.
Déclaration du kernel hacker Andrew Morton : This is a benefit to the Linux development community and we appreciate Coverity's efforts to help us improve the security and stability of Linux. We've already addressed the top priority bugs that Coverity has uncovered. It's a very useful system for high quality code."
Il est à noter que cette analyse n'est rendue possible que par la disponibilité des sources ce qui contraste singulièrement avec la situation de beaucoup d'autres systèmes dont la qualité est difficilement vérifiable (voilà un avantage réel et indiscutable de l'Open Source).
Enfin on peut évoquer le logiciel SPARSE qui est développé par Linus Torvalds lui-même afin de constituer une alternative libre à SWAT.
je comprend pas trop...
Comment un logiciel peut-il détecter des bugs ?
Pour moi, un bug est quand un programmeur a mal exprimé ce qu'il voulait faire dans le langage de programmation.
Quand on programme, on part du principe que le langage fait exactement ce qu'on lui dit de faire.
En gros, je ne comprend pas trop comment fonctionne ce genre de logiciel ni quels genre de bugs il peut trouver et surtout, pourquoi c'est pas intégré dans le compilateur directement.
-
[^]Re: je comprend pas trop...
Posté par ArBaDaCarBa () le 16/12/2004 à 23:35. (lien). Évalué à 10.Je ne me souviens plus trop des détails, mais l'article de Linux Mag l'explique pas trop mal:
http://www.linux-mag.com/2004-04/code_01.html(...)
-
[^]Re: je comprend pas trop...
Posté par cykl (Jabber id, ) le 16/12/2004 à 23:53. (lien). Évalué à 10.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 Fanf () le 17/12/2004 à 06:18. (lien). Évalué à 10.> 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 ? :-)
Ou plutot parce que généralement, les outils d'analyse statique sont lents et pas pousse-boutons : il faut beaucoup de calculs pour obtenir des résultats (et donc beaucoup de temps) qui doivent être analysé par la suite. DE plus, il faut parfois rajouter des hypothèses lors de l'analyse pour obtenir un résultat utilsable. Evidemment, pas n'importe quelle hypothèses non plus, et c'est là encore un difficulté (par exemple, donner un invariant de boucle à l'outils qui ne sait généralement pas le trouver, mais qui est essentiel pour vérifier la terminaison de celles-ci).
Bref, tout ça pour dire que tu ne peux pas forcément intégrer les outils d'analyse statique au compilo, mais ça n'empeche pas d'en avoir des libres.-
[^]Re: je comprend pas trop...
Posté par Matthieu Moy (page perso, ) le 17/12/2004 à 08:38. (lien). Évalué à 10.C'est aussi parce que ce que fait ce genre d'outil est indécidable dans le cas général. Donc, l'outil fait ce qu'il peut, mais aura toujours des faux positifs et/ou des faux négatifs. Or, le boulot d'un compilo, c'est de compiler les programmes corrects (éventuellement avec warnings) et de refuser les autres, et on aime bien que les règles qui disent comment le compilo choisi dans quel cas on est soient claires.
-
[^]Re: je comprend pas trop...
Posté par morfal () le 20/12/2004 à 14:36. (lien). Évalué à 5.Donc, l'outil fait ce qu'il peut, mais aura toujours des faux positifs et/ou des faux négatifs.
En effet, d'après http://www.linux-mag.com/2004-04/code_01.html(...)
"Using the most recent advances in source code analysis, the types of bugs described in this article can be found in code bases the size of Linux with a false positive rate of less than 20%."
En français :
Le taux de faux positifs - c'est à dire des non-bugs détectés comme bugs par l'outil d'analyse de code - est inférieur à 20% avec les techniques récentes.
On peut en déduire que 185 des 985 bugs n'en sont pas. Mais bien sûr ce sera compensé par tous les bugs non détectés...
M
-
-
-
-
[^]Re: je comprend pas trop...
Posté par _alex () le 17/12/2004 à 13:45. (lien). Évalué à 3.Pour le java, il y a FindBugs, il y a la liste des bugs détectés : http://findbugs.sourceforge.net/bugDescriptions.html(...)
ca peut donner une idée. Il faut trier un peu trier le résultat, mais c'est deja pas mal.
-
[^]Re: je comprend pas trop...
Posté par Lionel Draghi (page perso, ) le 17/12/2004 à 23:10. (lien). Évalué à 3.Comment un logiciel peut-il détecter des bugs ?
Si tu veux un panel complet en quelques pages des techniques de vérification, tu peux lire le chapitre "Verification Techniques" du Guide d'utilisation d'Ada dans les systèmes de haute intégrité http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c029575_I(...)).zip
En gros, je ne comprend pas trop [...] pourquoi c'est pas intégré dans le compilateur directement.
Le compilateur ne peut pas faire de miracle : en amont, il y a la définition du langage utilisé. Si la définiton est imprécise, et la sémantique de bas niveau, la tâche devient virtuellement impossible pour les outils d'analyse statique.
Alors à fortiori pour le compilateur dont ce n'est pas la vocation.
-
[+] [^]Re: je comprend pas trop...
Posté par BugMeNot ! (page perso, ) le 18/12/2004 à 10:51. (lien). Évalué à -1.On peut dire qu'effectivement c'est plein de bug ... et alors ? comme tout. Le seul truc c'est que ca foncitonne pas comme tout :)
Coverity
Je me souviens avoir voulu essayer Coverity après avoir lu un article dans Linux Magazine (US). Leur produit à l'air extrêmement bien, mais pas vraiment facile à utiliser. On peut le tester gratuitement après enregistrement, mais l'outil d'analyse reste du coté de leur machines, il faut uploader un rapport. Pas forcément très convivial, surtout quand on en a pas vraiment l'utilité (mon cas).
Du coup, je ne l'ai pas essayé... mais j'ai tout de même reçu un mail (qui semblait réellement écrit par un humain, c'est rare) pour me demander ma satisfaction. C'était plutôt gentil.
Bref, ils ont l'air de faire du bon boulot :)
-
[^]Re: Coverity
Posté par Sylvain Sauvage () le 17/12/2004 à 00:23. (lien). Évalué à 6.(qui semblait réellement écrit par un humain, c'est rare)
Ils se servent d'un « analyseur statique » de messages automatiques...
Tout est relatif
Je pense que tout est relatif, même quand on regarde le chiffre annoncé de 985 bugs, la perfection n'existe pas et heuresement !
Je me pose une question, est-ce que il va y avoir une réaction de linus face à ce genre de rapport ?
-
[^]Re: Tout est relatif
Posté par Pierre Jarillon (page perso, ) le 17/12/2004 à 01:57. (lien). Évalué à 7.Le chiffre peut paraitre énorme, mais il faut savoir que 99% des bugs sont répartis dans des centaines de drivers et qu'on est loin d'en utiliser autant sur une seule machine.
D'autre part certains bugs ont une probabilité d'apparition extrêmement faible voire nulle. D'autres peuvent avoir des conséquences négligeables.
Si on estime selon l'article que pour 1000 lignes de code, Windows a 2 bugs et Linux 0.17, on peut en déduire que Linux est 10 fois plus stable que windows. Intéressant... et à retenir !-
[^]Re: Tout est relatif
Posté par pasBill pasGates () le 17/12/2004 à 03:40. (lien). Évalué à 8.Si on estime selon l'article que pour 1000 lignes de code, Windows a 2 bugs et Linux 0.17, on peut en déduire que Linux est 10 fois plus stable que windows.
Ce qui est une estimation ridicule...
MS utilise ce genre d'outils depuis 2 ans maintenant sur le code des nouveaux OS. Il y a donc de fortes probabilites que cet outil la en aurait trouve bcp moins si il avait ete passe sur Windows vu qu'une passe du meme type a deja ete faite et les bugs corriges.
Ca ne veut pas dire qu'il y a forcement moins de bugs dans l'un ou dans l'autre cependant, vu que ce type d'outil ne trouve que qqe categories de bugs.-
[^]Re: Tout est relatif
Posté par harbort1 () le 17/12/2004 à 08:21. (lien). Évalué à 10.MS utilise ce genre d'outils depuis 2 ans [...]
D'un autre côté, comme personne n'utilise de Windows de moins de 2 ans ... :P-
[^]Re: Tout est relatif
Posté par pasBill pasGates () le 17/12/2004 à 08:27. (lien). Évalué à 1.Windows Server 2003 & XP SP2
Et XP SP2 ca fait bcp de monde...-
[^]Re: Tout est relatif
Posté par vincent LECOQ (Jabber id, page perso, ) le 17/12/2004 à 08:51. (lien). Évalué à 6.pas moi !
et tout les utilisateurs lambda non plus ...
2003 server est rare sur les postes prives, et le SP2, je connais plus de monde qui a eu des soucis avec que de gens qui le connaissent.--
Ma signature ici-
[^]Re: Tout est relatif
Posté par tuiu pol (Jabber id, ) le 17/12/2004 à 10:15. (lien). Évalué à 3.pas moi !
t'es sur linuxfr, on s'attend pas à ce que la majorité pésente utilise intensivement les produits MS. C'est pas super représentatif du reste du monde.-
[^]Re: Tout est relatif
Posté par Axel R. (page perso, ) le 17/12/2004 à 14:31. (lien). Évalué à 9.la majorité pésente utilise intensivement les produits MS
ça depend, moi j'adore leurs joysticks et leurs souris :-)
Axel-
[^]Re: Tout est relatif
Posté par Olivier Dzwoniarkiewicz (page perso, ) le 17/12/2004 à 20:58. (lien). Évalué à 2.et leurs claviers aussi sont très confortables :-)
-
[^]Re: Tout est relatif
-
-
[^]Re: Tout est relatif
Posté par Pierre Jarillon (page perso, ) le 18/12/2004 à 03:26. (lien). Évalué à 3.J'approuve tout à fait, les souris femelles (sans boules) marquées Microsoft sont excellentes. Mais je me demande qui peut bien les fabriquer ?
-
[^]Re: Tout est relatif
-
[^]Re: Tout est relatif
Posté par jeff110 () le 13/01/2005 à 01:19. (lien). Évalué à 1.Un certain nombre de souris sont sous-traité chez ST.
Ceci dis, j'ai deja dans mon entourage pas moins de 7 souris microsoft qui sont tombées en panne a plus ou moins longt terme.
C'est la seule marque chez qui jai constaté des defaillances, meme en regardant du coté des génériques.
Donc si je dois choisir entre une Microsoft et une logitheque, mon coeur va pour logitech.
Enfin, je sais pas si certains ont essayer d'ouvrir une souris microsoft, mais à moins de casser le boitier, c'est quasiment impossible.
( deux visses sur ma logitech ).-
[^]Re: Tout est relatif
Posté par Sayena Yefka () le 13/01/2005 à 14:17. (lien). Évalué à 1.Tu ouvres souvent une souris optique ?
-
[^]Re: Tout est relatif
Posté par jeff110 () le 13/01/2005 à 22:39. (lien). Évalué à 1.Lorsque le fil de ta souris a un mauvais contact ( rare, mais j'ai deja vus ça deux fois avec les souris m$), ça peut être pratique d'ouvrir ta souris pour faire la reparation toi meme.
En ce qui me concerne, j'ai voulu modifier ma souris optique sans fils logitech car je la trouvais lourde et couteuse en batterie.
Je lui ai donc ouvert le ventre, puis j'ai remplacé les piles par un gros condensateur ( 7 Farad sous 3v ).
Le condensateur se recharge presque instatanement lorsque je passe ma souris sur le tapis.
celui-ci est recouvert de deux feuille d'alluminium, elle meme relier à une petite alimentation secteur.
-
-
-
-
-
-
[^]Re: Tout est relatif
Posté par pasBill pasGates () le 17/12/2004 à 20:24. (lien). Évalué à 1.Chacun son truc, moi je regardes les stats et elles sont claires, ton cas particulier lui c'est autre chose et il est loin de refleter la realite.
-
-
[^]Re: Tout est relatif
Posté par cortex62 (page perso, ) le 17/12/2004 à 11:21. (lien). Évalué à 2.Et XP SP2 ca fait bcp de monde...
Pas tant que ça, beaucoup reviennent au sp1. À tort ou à raison, mais c' est le cas.--
L'erreur est humaine, mais un véritable désastre nécessite un ordinateur.-
[^]Re: Tout est relatif
Posté par pasBill pasGates () le 17/12/2004 à 18:47. (lien). Évalué à 0.Beaucoup ca reste a voir, il y en a certainement, de la a ce que ce soit la majorite il y a un enorme pas que je ne franchis pas pour la simple raison que les chiffres de Windows Update montrent que ce n'est pas le cas, le SP2 s'est tres vite repandu.
-
[^]Re: Tout est relatif
Posté par MrLapinot (Jabber id, page perso, ) le 17/12/2004 à 19:46. (lien). Évalué à 1.Je ne sais pas lequel de vous deux a raison mais le fait est que le monsieur a dit que les gens "reviennent" au sp1. Ce qui signifie(rait) qu'ils installent puis désinstallent le sp2. Auquel cas les chiffres de windows update ne veulent plus rien dire... (à moins que windows update ne soit aussi prévenu quand tu désinstalles un logiciel - ils iraient jusque là ?)
-
[^]Re: Tout est relatif
Posté par pasBill pasGates () le 17/12/2004 à 20:17. (lien). Évalué à 1.WindowsUpdate donne les updates systemes, et vu qu'il doit savoir quel patch te donner il sait quel niveau de service pack tu as bien evidemment. Les chiffres sont la, bcp de gens sont sur le SP2. Si ils etaient repasses sur le SP1 ils apparaitraient dans la colonne SP1.
-
[^]Re: Tout est relatif
Posté par Matthieu Moy (page perso, ) le 17/12/2004 à 22:24. (lien). Évalué à 2.Je ne suis pas trop d'accord avec le raisonnement, vu que les gens qui désinitallent SP2 sont plutôt du genre a ne plus remettre les pieds sur WindowsUpdate, mais pour la conclusion, oui, puisque d'autres stats le montrent :
http://www.xitimonitor.com/etudes/equipement0.asp(...)-
[^]Re: Tout est relatif
Posté par pasBill pasGates () le 17/12/2004 à 22:54. (lien). Évalué à 2.Ben justement, ce qui ne vont pas sur WindowsUpdate ne sont pas comptabilises... WindowsUpdate connait le nombre de machines avec SP2 qui le contactent chaque mois, et MS connait grossierement le nombre de XP dans la nature --> proportion
-
[^]Re: Tout est relatif
Posté par Ontologia (page perso, ) le 18/12/2004 à 10:00. (lien). Évalué à 2.Donc la question est pluttot de savoir si l'ensemble des encore connectés à WindowsUpdate est repréentatif statistiquement des non connectés. Dans ce cas, bcp seraient passés au SP2.
Cela dit je connais effectivement pas mal de monde qui sont passés au SP2 et qui ont rétroinstallé en virant WindowsUpdate ("ça me pose plus de pb qu'autre chose" me dit-on en général)
Sans vouloir lancer le troll. Le seul avantage que je connais à Linux par rapport à win, c'est que sous linux la mémoire est beaucoup mieux gérée, et que windows laisse une impression à l'utilisation de système baclé.
Tiens en ce moment, je suis sous le xp d'un copain, ben qd j'ouvre explorer sur un simple répertoire contenant des archives et des vidéo, explorer fige, je suis obligé de le redémarer. J'accède au répertoire en tappant son chemin dans la barre d'adresse, ça marche !!
Tu vois, pBpG, windows, c'est toujours comme ça. J'en gère 35 dans ma boite et je n'ai que des problèmes de ce style.
Windows, c'est baclé, c'est pas fignolé comme système.
Malgré cela il a de grandes qualités et reste, sur le papier une vrai merveille que linux aura du mal à atteindre. Le problème c'est que le code ne réalise pas tout ce que Bilou a voulu que windows fasse...
Bon, je suis légèrement HS
-
[^]Re: Tout est relatif
Posté par Nicolas Boulay () le 19/12/2004 à 11:03. (lien). Évalué à 3.Donc un gusse qui a installé un sp2, puis devant les problèmes à réinstaller windows et désactivé windows update pour rester avec le sp1, est compté comme ayant installer un sp2 ?
-
[^]Re: Tout est relatif
Posté par pasBill pasGates () le 19/12/2004 à 21:15. (lien). Évalué à 1.Ben si il passe sur WU quand il a SP2 il est compte pour le SP2, si le mois suivant il passe pas car il est repasse en sp1 et desactive WU il est pas compte, etc...
C'est des statistiques a intervalles reguliers, ils font pas une statistique un jour donne et s'arretent la bien evidemment.
-
-
-
-
-
-
-
-
-
-
[^]Re: Tout est relatif
Posté par freeture () le 17/12/2004 à 10:44. (lien). Évalué à 6.... Et le code de windows étant fermé on ne poura de toute façon pas vérifier ...
-
[^]Re: Tout est relatif
Posté par Matthieu Moy (page perso, ) le 17/12/2004 à 12:05. (lien). Évalué à 3.A mon avis, si les gens de Coverity veulent analyser le code de windows, MS se fera un plaisir de leur fournir les sources. Par contre, c'est pas dit qu'ils aient le droit de publier les résultats ...
-
[^]Re: Tout est relatif
Posté par plagiats () le 17/12/2004 à 16:15. (lien). Évalué à 2.MS se fera un plaisir de leur fournir les sources
Bah tiens:
http://www.linuxfr.org/comments/347019.html#347019(...)--
La mort est un phénomène naturel qui se produit par l'avalement répété de petites quantités de salive au cours d'une grande période de temps. - George Carlin
-
-
-
[^]Re: Tout est relatif
Posté par llabe syl () le 18/12/2004 à 22:05. (lien). Évalué à 0."MS utilise ce genre d'outils depuis 2 ans maintenant sur le code des nouveaux OS"
euh franchement j'en doute....... ça te dit quelque chose ms03-039 ?.
ou peut être que tout est relatif..-
[^]Re: Tout est relatif
Posté par pasBill pasGates () le 18/12/2004 à 22:20. (lien). Évalué à 1.Oui ca me dit qqe chose, mais il faut bien comprendre que ces softs ne trouvent pas tous les bugs.
-
-
-
[^]Re: Tout est relatif
Posté par real_pouet () le 17/12/2004 à 17:16. (lien). Évalué à 9.Si on estime selon l'article que pour 1000 lignes de code, Windows a 2 bugs et Linux 0.17, on peut en déduire que Linux est 10 fois plus stable que windows. Intéressant... et à retenir !
bof pas vraiment non. l'utilisateur lambda (99% des gens faut il le rappeler?) il s'en fout que ce soit linux ou kde qui plante, pour lui "linux plante". Bref la stabilite de linux c est surement tres bien, mais ce n'est interessant que si les appli utilisateurs sont elles aussi stables. De plus les problemes de windows sont souvent du a ce qui se trouve entre la chaise et le clavier. Quand je vois des gens qui se loge en root sous KDE, je suis dubitatif vis a vis de la securite du systeme.
Enfin windows a prouve que les utilisateurs preferaient les fonctionnalites et la simplicite(?) a la stabilite et la securite.
et puis accessoirement, mon XP ne plante jamais (mon linux non plus :) ).
--
pouet-
[^]Re: Tout est relatif
Posté par alain prima () le 18/12/2004 à 09:23. (lien). Évalué à 1."Quand je vois des gens qui se loge en root sous KDE, je suis dubitatif vis a vis de la securite du systeme."
Je reste, en ce qui me concerne, dubitatif sur ce genre d'assertion "gratuite"!
Ce qui est à mettre en cause là, c'est l'éducation de l'utilisateur plutôt que la sécurité système.-
[^]Re: Tout est relatif
Posté par chl (page perso, ) le 18/12/2004 à 16:12. (lien). Évalué à 3.De la meme façon que les gens qui se connectent sur MS\Windows XP en administrateur, ou sous KDE, GNOME en root, il y aura de plus en plus de virus sous GNU/Linux.
Tant mieux, les migrations n'en seront que plus douces pour les utilisateurs venant de MS\Windows.
-
-
-
-
[^]Re: Tout est relatif
Posté par SoWhat () le 17/12/2004 à 07:28. (lien). Évalué à 7.a perfection n'existe pas et heureusement !
Qu'est-ce qu'on peut lire comme bêtises parfois.-
[^]Re: Tout est relatif
Posté par skasowac () le 17/12/2004 à 11:11. (lien). Évalué à 4.Non franchement, c'est pas ridicule ! Mais ça tient plutot de discussions philosophiques sur l'existence et tout ça ;-)
maintenant, on la cherche cette perfection, c'est ça qui compte....-
[^]Re: Tout est relatif
Posté par pada (page perso, ) le 17/12/2004 à 13:23. (lien). Évalué à 7.Oui, ne c'est pas ridicule, quelque chose de parfait n'a plus besoin d'évoluer. La déviance et l'erreur sont les sources de l'évolution nous apprennent les biologistes, les philosophes, les systémiciens ... bref tous ceux qui s'intéressent à la vie et à son évolution.
-
-
[^]Re: Tout est relatif
Posté par hervé Couvelard (Jabber id, page perso, ) le 17/12/2004 à 12:51. (lien). Évalué à 5.Non ce n'est pas une bétise du tout :
quel serait l'avenir d'une communauté (de LL par exemple) ou tout serait parfait ?
quoi faire de plus ? rien puisque tout est parfait , tout ce que tu peux faire en plus ne peux QU'ajouter de l'imparfait au passé déja composé parfait, le plus que parfait n'étant pas possible, quel futur dans tout cela ?
C'est vrai c'est plus philosophique que informatique-
[^]Re: Tout est relatif
Posté par Yusei () le 17/12/2004 à 13:02. (lien). Évalué à 6.Il y a quand même la place pour pas mal de choses entre le "rien n'est parfait" et le "tout est parfait", non ? :)
-
[^]Re: Tout est relatif
Posté par hervé Couvelard (Jabber id, page perso, ) le 17/12/2004 à 15:19. (lien). Évalué à 1.la perfection est un état que nous tentons de rejoindre asymptotiquement.
Je n'ai malheureusement pas connaissance autour de moi de quelquechose de parfais (ok je ne dis pas heureusement :-)-
[^]Re: Tout est relatif
Posté par zero heure (Jabber id, page perso, ) le 17/12/2004 à 18:11. (lien). Évalué à 4."Ne crains pas la perfection, tu ,ne l'atteindra jamais"
Salvador Dali
(dans ses Conseils pour devenir peintre, je crois)--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
-
-
-
[^]Re: Tout est relatif
Posté par Gui (Jabber id, ) le 17/12/2004 à 13:26. (lien). Évalué à 6.en fait, c'est plus l'erreur orthographique du mot heureusement qui est la bétise (l'auteur original avait écrit "heuresement")... pas la référence philosophique à la perfection.
moi aussi je suis tombé dans le panneau au début :)
mais bon, un score de 9 (au moment où j'écris) pour une simple correction de français, c'est un peu énorme... à mon avis tout le monde à du pensé que c'était un commentaire philosophique
-
-
13 % de « code mort »
Euh, est-ce que les bogues trouvés dans le code mort (dead code) sont comptés ?
Si c'est le cas, Linux vient de perdre d'un coup environ 13 % de bogues :oP
-
[^]Re: 13 % de « code mort »
Posté par ploum (page perso, ) le 17/12/2004 à 01:40. (lien). Évalué à 4.il y'a eu un gros nettoyage ?
-
[^]Re: 13 % de « code mort »
Posté par iouri () le 17/12/2004 à 02:23. (lien). Évalué à 5.Ben par définition le code mort n'est jamais exécuté, donc c'est autant de bugs qui ne poseront jamais de problème.
-
[^]Re: 13 % de « code mort »
Posté par frayd () le 17/12/2004 à 05:22. (lien). Évalué à 3.Comment est-on sûr qu'il ne sera jamais exécuté ?
En théorie, il ne sera pas exécuté http://www.linux-france.org/prj/jargonf/C/code_mort.html(...)
Mais est-ce qu'un pointeur mal ficelé ne peut pas aller le réveiller ?
Dans mon job, une appli avait dérapé et les développeurs avaient expliqué ce dérapage à cause de la présence de code mort.-
[^]Re: 13 % de « code mort »
Posté par dromadaire35 () le 17/12/2004 à 07:32. (lien). Évalué à 3.est-ce qu'un pointeur mal ficelé ne peut pas aller le réveiller ?
Si ton code est mort, il est mort. Si un pointeur est mal ficelé, ça a faire du dégat, code mort ou pas.-
[^]Re: 13 % de « code mort »
Posté par CoinKoin () le 17/12/2004 à 08:10. (lien). Évalué à 6.Si ton code est mort, il est mort.
Ben non, justement... Si ton code est mort, cela signifie que tu estimes qu'il ne sera jamais exécuté, pas qu'il ne le sera jamais dans l'absolu. Considère l'exemple suivant : int main(int argc, char** argv){ if((argc==1)||(argc>=3)) { fprintf(stderr,"usage : truc [fichier]\n"); exit(1); fprintf(stderr,"Code mort 1\n"); } else if(argc==2){ fprintf(stdout,"Truc a été bien appelé!\n"); exit(0); fprintf(stderr,"Code mort 2\n"); } else{ fprintf(stderr,"Code mort 3\n"); } } Il y a trois morceaux de code mort, dont on peut raisonnablement espérer qu'ils ne seront jamais exécutés. Malheureusement, ce n'est pas vraiment le cas : -Si on se lie avec des bibliothèques non-standards, exit() peut être bogué et revenir; -La troisième portion n'est de toutes façons pas morte, puisqu'on peut avoir argc==0 (même si c'est assez rare). Donc le programmeur a inclus du code "mort", pour détecter des problèmes, et ce code peut effectivement être exécuté dans certains cas.-
[^]Re: 13 % de « code mort »
Posté par Guinns (page perso, ) le 17/12/2004 à 08:57. (lien). Évalué à 3.Ce n'est pas vraiment ca du "code mort" ... comme tu l'expliques on ne peut pas se baser sur les actions présumées d'une fonction ...
Voici un exemple de code mort:
{
int i=0;
if(i>10)
{ /* voici du code mort car i ne sera jamais > à 10 ici */
ma_fontion();
}
}
Pour ceux qui pensent au multithread, noter que 'i' n'est pas static ou global ...-
[^]Re: 13 % de « code mort »
Posté par CoinKoin () le 17/12/2004 à 09:18. (lien). Évalué à 3.Ben, ton exemple correspond à ma troisième erreur... Dans laquelle le programmeur CROYAIT que argc était toujours supérieur ou égal à 1, mais ou il s'est trompé. Sinon, quel serait l'intérêt du code mort, à ton avis?
(Effectivement, dans ton exemple, le code mort ne sert à rien, mais, dans la réalité, il est justement assez difficile de garantir avec une totale certitude une affirmation du genre i ne sera jamais > à 10 ici).-
[^]Re: 13 % de « code mort »
Posté par Colin Leroy (page perso, ) le 17/12/2004 à 10:16. (lien). Évalué à 3.Je veux voir un exemple où argc==0.
-
[^]Re: 13 % de « code mort »
Posté par CoinKoin () le 17/12/2004 à 10:24. (lien). Évalué à 3.execvp("mon_prog",NULL) est autorisé sur certains systèmes, d'après mes souvenirs.
-
[^]Re: 13 % de « code mort »
Posté par Colin Leroy (page perso, ) le 17/12/2004 à 13:59. (lien). Évalué à 4.En effet, ça marche. Mea culpa, je n'aurais pas cru!
$ cat testargc.c int main(int argc, char *argv[]) { printf("argc = %d\n", argc); return 0; } $ cat testexec.c #include <unistd.h> int main (int argc, char *argv[]) { execvp("./testargc", NULL); return 0; } $ gcc -o testargc testargc.c; gcc -o testexec testexec.c $ ./testargc argc = 1 $ ./testexec argc = 0-
[^]Re: 13 % de « code mort »
Posté par Krunch (Jabber id, page perso, ) le 17/12/2004 à 15:36. (lien). Évalué à 3.D'après http://www-ccs.ucsd.edu/c/lib_over.html#program%20startup(...)
argc is a value (always greater than zero)
Donc je pense qu'on peut dire que c'est un bug (ça le fait aussi avec gcc --std=c89 mais c'est plutôt un problème de bibliothèque que de compilateur je pense).--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: 13 % de « code mort »
Posté par cykl (Jabber id, ) le 17/12/2004 à 17:20. (lien). Évalué à 5.Depuis quand une page sortie au hasard d'internet permet de dire que c'est un bug ?
Chez moi POSIX dit ca :
=======
Early proposals required that the value of argc passed to main() be "one or greater". This was driven by the same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no arguments are supplied to the caller of the exec functions. This requirement was removed from the ISO C standard and subsequently removed from this volume of IEEE Std 1003.1-2001 as well. The wording, in particular the use of the word should, requires a Strictly Conforming POSIX Application to pass at least one argument to the exec function, thus guaranteeing that argc be one or greater when invoked by such an application. In fact, this is good practice, since many existing applications reference argv[0] without first checking the value of argc.
=========
On notera le should !
Pour la norme C je te laisse chercher tout seul les outils pour lire du ps dans gnome sont tellement pratique qu'en 2004 y'a toujours pas la fonction "recherche"-
[^]Re: 13 % de « code mort »
-
[^]Re: 13 % de « code mort »
Posté par Krunch (Jabber id, page perso, ) le 18/12/2004 à 00:18. (lien). Évalué à 3.Et donc un commentaire venant de toi est censé être plus crédible qu'un page "au hasard" :)
Enfin, j'ai retrouvé ce que tu cites ici (ça effectivement c'est plus crédible): http://www.opengroup.org/onlinepubs/009695399/functions/exec.html(...)
Bon ba faudra que je dise à mon prof de C que les références qu'il nous a donné sont foireuses.
Sinon apparement ya un PDF de C99 là http://www.nirvani.net/docs/ansi_c.pdf(...) (trouvé sur Wikipedia) qui dit la même chose: (page 26)- The value of argc shall be nonnegative.
Moi on m'a toujours dit que zéro est à la fois négatif et positif mais bon deux lignes plus loin:- If the value of argc is greater than zero[...]
Ce qui suppose que argc peut valoir zéro.--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: 13 % de « code mort »
Posté par cykl (Jabber id, ) le 18/12/2004 à 08:43. (lien). Évalué à 2.> Et donc un commentaire venant de toi est censé être plus crédible qu'un page "au hasard" :)
Bien sur que non ! C'est simplement que c'est la norme :-)
Effectivement j'ai oublié de donner le lien je m'en excuse.
L'avantage c'est que dans la norme tu peux dire n'importe quoi tu es la norme !
> Bon ba faudra que je dise à mon prof de C que les références qu'il nous a donné sont foireuses.
Il me semble deja avoir vu passer ce lien et qu'il est pas mal. Ca ne l'empeche pas de dire au moins une connerie et si c'est la seule il est tres largement au dessus de la moyenne :-)
-
[^]Re: 13 % de « code mort »
-
-
-
-
-
-
-
-
[^]Re: 13 % de « code mort »
Posté par zzmaxfr () le 17/12/2004 à 09:30. (lien). Évalué à 1.Malgrés que cela puisse paraitre un peu capilotracté, il existe les single event (une particule lourde qui passe par la) et pour la valeur du registre change. Dans des environnements radioactifs, spacial ou haute altitude on peut s'amuser à les détecter avec ce genre de code.
-
[^]Re: 13 % de « code mort »
Posté par CoinKoin () le 17/12/2004 à 09:40. (lien). Évalué à 2.Il y a moins capillotracté... Un signal jaillit, et le sig_handler, codé en assembleur, est bogué et modifie certaines valeurs contenues dans les registres du processeur ou sur la pile. Ca surprend, mais ça marche...
-
[^]Re: 13 % de « code mort »
Posté par _alex () le 17/12/2004 à 13:52. (lien). Évalué à 4.x86-secret parle d'un bug de memtest86 pour un type de CPU et pas un autre (reste du matériel indique) :
http://www.x86-secret.com/popups/articleswindow.php?id=115(...)
A priori on peut se dire que c'est un bug matériel, et en fait non ...
-
-
-
-
[^]Re: 13 % de « code mort »
Posté par gc (page perso, ) le 17/12/2004 à 09:15. (lien). Évalué à 5.si argc peut être 0, alors ton "code mort 3" n'en est pas.
du code mort, c'est lorsque la sémantique du langage fait que le code ne peut pas être exécuté, quelles que soient les données : si ton premier test était argc <=1, si tu mets du code après un return (et que le compilo l'autorise). et effectivement compter sur exit() n'est pas bon.-
[^]Re: 13 % de « code mort »
Posté par CoinKoin () le 17/12/2004 à 09:25. (lien). Évalué à 0.Heu, à priori, c'est pas ça la définition du code mort...
Ca, c'est une définition trop forte. Pour moi, le code mort, c'est un code dont le programmeur à la conviction qu'il ne sera jamais exécuté, mais qu'il met quand même, pour éviter les mauvaises surprises.
C'est très employé dans les applications critiques, pour justement se garantir contre les fautes de programmation (le pilote de ligne a rarement vi, gdb et gcc sous la main pour déboguer en vol le pilote automatique en cas de pépin).
(Cela dit, c'est vrai que le nom n'est pas très bon : il vaudrait mieux l'appeler code pseudo-mort, puisque l'on n'est pas absolument sûr qu'il l'est. Je pense que c'est ce problème de dénomination qui gêne.)-
[^]Re: 13 % de « code mort »
Posté par bartman () le 17/12/2004 à 10:23. (lien). Évalué à 4.moi qui pensait que le code mort concernait aussi (comprendre surtout) les instructions que le développeur insère dans le but qu'il soit exécuté, mais à l'analyse du programme ont s'apperçoit que ce ne
sera pas le cas.
Jamais exécuté ? on ne parle pas de probabilité, càd code mort = code 0% de possibilité d'éxécution ou il existe quelques possibilitées pour que cela arrive sachant que les conditions liées à des enchainements en run-time : l'utilisateur à créé une circonstance, un état "buggé" par la suite de ses actions.
Je doute que l'analyseur de code puisse prendre la totalité de ces probabilités.
PS : et pas 13% de bug en plus du au code mort, sinon ça ferait 100% de bug dedans, je doute que les développeurs du kernel soient si mauvais--
Parler pour ne rien dire et ne rien dire pour parler sont les deux principes majeurs et rigoureux de tous ceux qui feraient mieux de la fermer avant de l'ouvrir.-
[^]Re: 13 % de « code mort »
Posté par Mickaël L () le 17/12/2004 à 11:46. (lien). Évalué à 2.>amais exécuté ? on ne parle pas de probabilité, càd code mort = code 0% de possibilité
> d'éxécution ou il existe quelques possibilitées pour que cela arrive sachant que les conditions
> liées à des enchainements en run-time
C'est rigolo, parce qu'un évènement de probabilité 0 n'est pas forcément impossible ;)-
[^]Re: 13 % de « code mort »
Posté par Sebastien Binet () le 17/12/2004 à 18:20. (lien). Évalué à 3.Ca dépend de la définition de la probabilité que tu utilises (à savoir : fréquentiste ou bayesienne ?).
Un fréquentiste te diras qu'un événement de probabilité 0, aura une fréquence d'apparition de 0 sur 100 tirages (ensuite il y a le problème de savoir l'erreur sur cette affirmation).
Un Bayésien te donne juste sa confiance en le fait que tel ou tel évènement se produise.
Donc à mon avis pour ce genre d'évènement (un muon cosmique qui traverse un transistor, communique la bonne énergie au bon electron pour le faire sauter de niveau d'énergie au "bon" moment) qui est somme toute assez rare (à l'abri de notre bonne vieille atmosphère, et assez loin de toute source de radiations), il vaut mieux accompagner toute probabilité d'une bonne dose de "niveau de confiance" que l'on veut bien lui associer.
Voilà, c'était juste la petite minute de quadri-pilo-sectomie...-
[^]Re: 13 % de « code mort »
Posté par _alex () le 17/12/2004 à 18:53. (lien). Évalué à 1.Comme disait mon prof de math, tout arrivera, y compris le jour où la craie monte au plafond.
-
[^]Re: 13 % de « code mort »
Posté par Sebastien Binet () le 17/12/2004 à 19:03. (lien). Évalué à 2.Et comme tout bon prof de maths il se plaçait dans un cadre mathématique solide et consistent et pouvait dire que si on a à notre disposition assez de temps pour regarder si la craie monte au plafond, un temps au minimum infini, alors on pourra voir la craie monter au plafond.
Mais pour cela, il faut quelqu'un qui ait du temps (un fonctionnaire ?;), et il faut un temps infini.
Pour la première hypothèse, on peut trouver quelqu'un (si c'est bien payé).
La deuxième est nettement plus hasardeuse : qui peut m'affirmer/me-démontrer dans la salle que l'univers est éternel ? :P
-
-
[^]Re: 13 % de « code mort »
Posté par gph () le 19/12/2004 à 17:24. (lien). Évalué à 1.Moi je dirais surtout que ca dépend de la mesure de probabilité. Enfin bref on peut trouver des ensembles non vide de mesure nulle (un point sur la droite des Réelles, par rapport à la mesure de Lebesgue par exemple). Donc voila l'evement faire une coupe sur un ruban tout pile sur un point donné doit bien avoir une probabilité nulle, mais il se peut quand même qu'il se produise. (d'accord c'est vraiment pas de chance)
-
-
-
-
[^]Re: 13 % de « code mort »
Posté par Nicolas Boulay () le 17/12/2004 à 10:36. (lien). Évalué à 3.ah le code mort de surveillance d'une variable dont on se fout qui fait partir l'équipement en autotest en plein vole...
-
[^]Re: 13 % de « code mort »
Posté par Papey () le 17/12/2004 à 12:32. (lien). Évalué à 9.Le code mort, c'est du code qui était vivant mais qui ne l'est plus. Typiquement, tu écris une fonction qui n'est appelée qu'à un endroit de ton code, puis tu changes le code l'appelant par une version n'utilisant plus ladite fonction. Comme tu es pressé et que tu as plein d'autres modifs à faire, et qu'en plus tu te dis que cette fonction pourra te re-servir un jour, tu ne vires pas son code de tes sources, bien qu'il ne soit plus appelé par personne.
-
[^]Re: 13 % de « code mort »
Posté par Nicolas Boulay () le 17/12/2004 à 12:38. (lien). Évalué à 1.Au vue des différences interprétations, du code mort, c'est du code qui ne sert à rien dans un cas d'utilisation """normal""".
Le cas du code mort en question était le traitement d'une variable à un endroit mais qui ne servait à un rien ensuite. Par contre, l'exception derrière a été fatal...
(je parle d'un cas très connu en fait...)-
[^]Re: 13 % de « code mort »
-
-
-
-
[^]Re: 13 % de « code mort »
Posté par Pascal Terjan (Jabber id, page perso, ) le 17/12/2004 à 12:19. (lien). Évalué à 5.Pour moi le code mort est du code ne pouvant pas être executé et que le compilateur doit essayer au maximum de supprimer.
Après tu as le code mort repérable par le compilo (if(0) par exemple ou if(3<2) après propagation des constantes), celui qui pourrait être repéré par le compilo mais moyennant des analyses trop complexes, et tu as le code mort parce que certaines valeurs de parametres exterieurs ne pourront/devront jamais arriver (et ca la plupart des languages ne peuvent pas l'exprimer proprement). D'ailleurs je me demande si gcc considère le bloc mort dans:
assert(i>5);
if(i<3){...}-
[^]Re: 13 % de « code mort »
Posté par Pascal Terjan (Jabber id, page perso, ) le 18/12/2004 à 11:35. (lien). Évalué à 2.Je viens de tester, gcc laisse le code, même en lui indiquant clairement avec
if(i<=5) assert(i>5); else if(i<3){printf("plop\n");}-
[^]Re: 13 % de « code mort »
Posté par Krunch (Jabber id, page perso, ) le 18/12/2004 à 13:08. (lien). Évalué à 2.Avec -O1 apparement il le laisse pas.
--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
-
-
-
[^]Re: 13 % de « code mort »
Posté par grafit () le 17/12/2004 à 12:43. (lien). Évalué à 3.>Heu, à priori, c'est pas ça la définition du code mort...
Ca, c'est une définition trop forte. Pour moi, le code mort, c'est un code dont le programmeur à la conviction qu'il ne sera jamais exécuté, mais qu'il met quand même, pour éviter les mauvaises surprises.
C'est original.
J'explique plutot le "code mort" par des raisons historiques. Du code qui servait au moment de son écriture, mais suite à l'évolution du code, il ne sert plus. Certe il y a les branches conditionelles dont une condition n'est plus jamais vérifiées (*), mais il a surtout les fonctions qui ne sont plus jamais appellées ou dont l'effet est ignoré. C'est du code *mort*.
Et effectivement il se peut qu'il y ai des bugs parmis ces lignes.
(*) que les amateurs de particules radioactives qui changent les valeurs du registre juste au moment du test, qui ne tentent pas de démontrer un cas général par un cas ultra particulier lèvent la main !
Cela dit, c'est vrai que le nom n'est pas très bon
Peut-être que c'est ta définition de "code mort" qui n'est pas très bonne... Il est évidant qu'elle ne colle pas avec l'expression. En tout cas, moi c'est la première fois que j'entends parler de code mort dans ce sens là. Une référence ?
-
[^]Re: 13 % de « code mort »
Posté par Lionel Draghi (page perso, ) le 17/12/2004 à 22:53. (lien). Évalué à 4.
Ca, c'est une définition trop forte. Pour moi, le code mort, c'est un code dont le programmeur à la conviction qu'il ne sera jamais exécuté, mais qu'il met quand même, pour éviter les mauvaises surprises.
La DO178 (qui est utilisée pour l'avionique critique), fait une distinction entre deactivated code et deadcode. Ce dont tu parles entre dans la catégorie deactivated.
Par exemple un traitement d'exception que l'on mets au cas ou, ou un if dépendant d'un booléen de configuration dont une des branches ne sera jamais exécuté dans cette configuration là. Le deactivated code n'est volontairement pas exécuté.
Le dead code n'est pas non plus exécuté, mais c'est par erreur, souvent détectable par les outils d'analyse statique, du genre :
if i > 10 then
if i < 3 then
-- dead code
end if;
end if;
-
-
-
-
-
-
-
-
[^]Re: 13 % de « code mort »
Posté par Matthieu Moy (page perso, ) le 17/12/2004 à 17:56. (lien). Évalué à 4.13%, c'est 13% des bugs trouvés, pas 13% du code ...
-
[^]Re: 13 % de « code mort »
Posté par Sylvain Sauvage () le 17/12/2004 à 18:28. (lien). Évalué à 3.Exact. 50 réponses dans le fil et personne ne l'avait encore relevé. Comme quoi avec des chiffres, on peut dire ce qu'on veut (surtout quand ça fait plaisir ;o).
Par contre, on ne sait pas (d'après ces seules statistiques) si les bogues trouvés dans le code mort sont comptés ou pas. S'ils ne sont pas comptés : tant pis. S'ils le sont : en supprimant le code mort, on les supprime aussi (mais on a pas les chiffres pour l'estimer).
-
Seulement un sous-ensemble de tous les bugs
Cet outil ne peut trouver qu'un certain sous ensemble des bugs présents dans le code.
Il a déjà été appliqué de nombreuses fois au code de linux, et les bugs présents dans ce sous-ensemble ont été progressivement éliminés. Il est normal qu'il en reste très peu.
Donc cette statistique ne donne en fait que peu d'informations puisqu'un nombre inconnu de bugs indétectables par le programme subsistent.
-
[^]Re: Seulement un sous-ensemble de tous les bugs
Posté par patrick_g (page perso, ) le 17/12/2004 à 09:31. (lien). Évalué à 4.Cet outil ne peut trouver qu'un certain sous ensemble des bugs présents dans le code.
C'est bien pour cela que j'ai pris la peine d'écrire dans la news :
"Enfin il faut bien voir que ce total de 985 bugs est un chiffre absolument minimum qui omet toutes les erreurs existantes dans le noyau mais passant, pour une raison ou pour une autre, à travers les mailles de SWAT".
Oui, mais où ?
J'ai visité les stats. Quelqu'un a-t-il trouvé comment accéder aux détails de ces bugs ? Ligne de code, opération concernée, ... ?
Merci
CdM
-
[^]Re: Oui, mais où ?
Posté par patrick_g (page perso, ) le 17/12/2004 à 09:33. (lien). Évalué à 4.il faut contacter directement la société Coverity pour qu'il te refile le détail des bugs.
les devs du noyau l'on fait et on reçu l'analyse ce qui permet de corriger les erreurs.-
[^]Re: Oui, mais où ?
Posté par Ramoz () le 17/12/2004 à 22:00. (lien). Évalué à 2.il faut contacter directement la société Coverity pour qu'il te refile le détail des bugs.
les devs du noyau l'on fait et on reçu l'analyse ce qui permet de corriger les erreurs.
Est-ce que ça veut dire que après correction, plus aucun bug (ou presque) ne sera détecté avec ce soft ?
Dans ce cas-là, il serait intéressant d'analyser le code de n'importe quel logiciel avec plusieurs détecteurs de bug et on n'obtiendrait un programme assez propre non ?-
[^]Re: Oui, mais où ?
Posté par Pascal Terjan (Jabber id, page perso, ) le 17/12/2004 à 22:16. (lien). Évalué à 5.Oui c'est ce que Microsoft fait :)
-
-
Il y a dedans amha un paquet de faux positifs
Il y a dedans amha un paquet de faux positifs. En effet :
1) Dead code :
#define DEBUG 0
If (DEBUG)
.... /*code mort */
est du code mort mais pas du tout un bug (ce code sera d'ailleur supprimé par le compilateur que le détectera)
2) unusedvalue :
valeurnonutilisée = 0;
Est-ce vraiment une erreur ? C'est plutôt du code qui n'a pas été nettoyé...
Pour les autres points, il est également possible de trouver des cas qui ne correspondent pas a de bug. Le tout est de savoir si un être humain ets passé après le robot pour vérifier si c'est vraiment un bug...
Polyspace
Nous, au boulot, on utilise un outil apparement similaire : Polyspace de la société Polyspace Technologies.
http://www.polyspace.com/(...)
Je ne l'ai jamais utilisé personellement.
Est-ce que certains d'entre vous connaissent, et savez-vous si il a été passé sur le noyau ?
-
[^]Re: Polyspace
Posté par Germain Saval (Jabber id, ) le 17/12/2004 à 13:41. (lien). Évalué à 3.Je ne pense pas qu'il ait jamais été utilisé sur le noyau Linux, ceci dit le Verifier de Polyspace est un bon produit, quand on sait interpréter ses résultats. Il faut pas mal d'interventions manuelles pour obtenir un résultat satisfaisant, la réponse favorite étant "orange" (le code est coloré en fonction des erreurs détectées), c'est à dire "peut-être".
SWAT exempté?
Et le dit programme "SWAT", il en est à combien de bug? :)
moué...
-
[^]Re: SWAT exempté?
-
[^]d'ailleurs...
Posté par Matthieu C () le 17/12/2004 à 11:15. (lien). Évalué à 10.
ChangeSet@1.1907, 2004-09-02 17:00:19-07:00, torvalds@ppc970.osdl.org
The coverity source checker is wrong. Revert some of the "leak fixes".
Thanks to Davem for noticing. We probably should _not_ trust the
coverity reports that much.
Cset exclude: davej@redhat.com[torvalds]|ChangeSet|20040902213928|62770
Cset exclude: davej@redhat.com[torvalds]|ChangeSet|20040902213829|63705
-
[^]Re: SWAT exempté?
Posté par Germain Saval (Jabber id, ) le 17/12/2004 à 13:54. (lien). Évalué à 5.En principe, un outil d'analyse statique doit être prouvé formellement. En effet, il est inutile de vérifier un programme par un autre programme si les deux sont potentiellement aussi faux l'un que l'autre. Autant passer du temps en relecture de code. On doit donc déterminer le type d'analyse qu'on doit effectuer et les propriétés qu'on veut étudier et démontrer formellement (mathématiquement) que cette analyse fonctionne.
Le problème, c'est qu'il faut définir premièrement la sémantique du programme, c'est à dire du langage de programmation utilisé et deuxièmement, il faut se rendre compte que cette analyse est "moins précise" qu'une exécution exhaustive de tous les états possibles du programme, qui est infiniment précise mais aussi potentiellement infiniment longue. On doit donc s'assurer que notre représentation "moins précise" permet une analyse en temps fini et que les résultats ont encore un sens dans le programme réel : c'est un compromis pas toujours simple.
Tout ça pour dire que la plupart des analyseurs statiques du marché ont un noyau correctement prouvé, mais qu'on fait aussi pas mal de compromis pour obtenir un résultat raisonnable.-
[^]Re: SWAT exempté?
Posté par Romuald Delavergne () le 17/12/2004 à 14:45. (lien). Évalué à 5.En effet, il est inutile de vérifier un programme par un autre programme si les deux sont potentiellement aussi faux l'un que l'autre.
Du moment qu'il trouve des bugs que le développeur peut confirmer ensuite, ce n'est pas inutile.-
[^]Re: SWAT exempté?
Posté par Lionel Draghi (page perso, ) le 17/12/2004 à 23:44. (lien). Évalué à 0.Du moment qu'il trouve des bugs que le développeur peut confirmer ensuite, ce n'est pas inutile.
En général oui, mais pas toujours : pour une commande de vol électrique d'avion de ligne, il faut prouver que le logiciel est complètement correct.
Mais bon, comme passer d'un bon auxiliaire dans la chasse au bug à la preuve formelle du programme implique des changements considérables dans le processus et les outils de développement, ce n'est franchement pas applicable sur le kernel (et au logiciel libre en général, d'ailleurs).
-
-
Cette page a été générée par Templeet en 0.3974s (dont 0.0743 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.