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 Une analyse un peu plus fouillée de cette annonce laisse toutefois entrevoir plusieurs zones d'ombres.
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.
Aller plus loin
- Article de LWN sur l'annonce initiale (6 clics)
- Graphiques des bugs de Linux (5 clics)
- Le site de l'analyseur SWAT (5 clics)
- Les commentaires sur OSNews (3 clics)
- Un article sur SPARSE (3 clics)
# je comprend pas trop...
Posté par ploum (site web personnel, Mastodon) . Évalué à 9.
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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: je comprend pas trop...
Posté par ArBaDaCarBa . Évalué à 10.
http://www.linux-mag.com/2004-04/code_01.html(...)
[^] # Re: je comprend pas trop...
Posté par ckyl . É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 ? :-)
[^] # Re: je comprend pas trop...
Posté par Fanf (site web personnel) . Évalué à 10.
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 (site web personnel) . Évalué à 10.
[^] # Re: je comprend pas trop...
Posté par morfal . Évalué à 5.
"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 . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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
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 <s>BugMeNot</s> ! . Évalué à -1.
# Coverity
Posté par ArBaDaCarBa . Évalué à 8.
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 . Évalué à 6.
Ils se servent d'un « analyseur statique » de messages automatiques...
# Tout est relatif
Posté par xahlexx . Évalué à 2.
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 (site web personnel) . Évalué à 7.
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 . Évalué à 8.
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 . Évalué à 10.
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 . Évalué à 1.
Et XP SP2 ca fait bcp de monde...
[^] # Re: Tout est relatif
Posté par vincent LECOQ (site web personnel) . Évalué à 6.
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.
[^] # Re: Tout est relatif
Posté par tuiu pol . Évalué à 3.
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. (site web personnel) . Évalué à 9.
ça depend, moi j'adore leurs joysticks et leurs souris :-)
Axel
[^] # Re: Tout est relatif
Posté par Olivier Dzwoniarkiewicz . Évalué à 2.
[^] # Re: Tout est relatif
Posté par modr123 . Évalué à 4.
[^] # Re: Tout est relatif
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
[^] # Re: Tout est relatif
Posté par durandal . Évalué à 3.
[^] # Re: Tout est relatif
Posté par jeff110 . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Tout est relatif
Posté par jeff110 . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Tout est relatif
Posté par cortex62 . Évalué à 2.
Pas tant que ça, beaucoup reviennent au sp1. À tort ou à raison, mais c' est le cas.
[^] # Re: Tout est relatif
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: Tout est relatif
Posté par MrLapinot (site web personnel) . Évalué à 1.
[^] # Re: Tout est relatif
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Tout est relatif
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
http://www.xitimonitor.com/etudes/equipement0.asp(...)
[^] # Re: Tout est relatif
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Tout est relatif
Posté par Ontologia (site web personnel) . Évalué à 2.
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
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Tout est relatif
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Tout est relatif
Posté par pasBill pasGates . Évalué à 1.
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 . Évalué à 6.
[^] # Re: Tout est relatif
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: Tout est relatif
Posté par plagiats . Évalué à 2.
Bah tiens:
http://www.linuxfr.org/comments/347019.html#347019(...)
[^] # Re: Tout est relatif
Posté par llabe syl . Évalué à 0.
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 . Évalué à 1.
[^] # Re: Tout est relatif
Posté par real_pouet . Évalué à 9.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 3.
Tant mieux, les migrations n'en seront que plus douces pour les utilisateurs venant de MS\Windows.
[^] # Re: Tout est relatif
Posté par SoWhat . Évalué à 7.
Qu'est-ce qu'on peut lire comme bêtises parfois.
[^] # Re: Tout est relatif
Posté par skasowac . Évalué à 4.
maintenant, on la cherche cette perfection, c'est ça qui compte....
[^] # Re: Tout est relatif
Posté par pada . Évalué à 7.
[^] # Re: Tout est relatif
Posté par hervé Couvelard . Évalué à 5.
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 (Mastodon) . Évalué à 6.
[^] # Re: Tout est relatif
Posté par hervé Couvelard . Évalué à 1.
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 ZeroHeure . Évalué à 4.
Salvador Dali
(dans ses Conseils pour devenir peintre, je crois)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Tout est relatif
Posté par gde . Évalué à 6.
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 »
Posté par Sylvain Sauvage . Évalué à 5.
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 (site web personnel, Mastodon) . Évalué à 4.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: 13 % de « code mort »
Posté par iouri . Évalué à 5.
[^] # Re: 13 % de « code mort »
Posté par frayd . Évalué à 3.
En théorie, il ne sera pas exécuté http://www.linuxfr-france.org.invalid/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 . Évalué à 3.
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 . Évalué à 6.
[^] # Re: 13 % de « code mort »
Posté par Guinns . Évalué à 3.
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 . Évalué à 3.
(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 (site web personnel) . Évalué à 3.
[^] # Re: 13 % de « code mort »
Posté par CoinKoin . Évalué à 3.
[^] # Re: 13 % de « code mort »
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: 13 % de « code mort »
Posté par Krunch (site web personnel) . Évalué à 3.
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).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 13 % de « code mort »
Posté par ckyl . Évalué à 5.
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 »
Posté par Barnabé . Évalué à 1.
[^] # Re: 13 % de « code mort »
Posté par Krunch (site web personnel) . Évalué à 3.
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) Moi on m'a toujours dit que zéro est à la fois négatif et positif mais bon deux lignes plus loin: Ce qui suppose que argc peut valoir zéro.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 13 % de « code mort »
Posté par ckyl . Évalué à 2.
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 »
Posté par corn . Évalué à 3.
[^] # Re: 13 % de « code mort »
Posté par zzmaxfr . Évalué à 1.
[^] # Re: 13 % de « code mort »
Posté par CoinKoin . Évalué à 2.
[^] # Re: 13 % de « code mort »
Posté par _alex . Évalué à 4.
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 (site web personnel) . Évalué à 5.
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 . Évalué à 0.
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 . Évalué à 4.
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
[^] # Re: 13 % de « code mort »
Posté par mickabouille . Évalué à 2.
> 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 . Évalué à 3.
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 . Évalué à 1.
[^] # Re: 13 % de « code mort »
Posté par Sebastien . Évalué à 2.
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 . Évalué à 1.
[^] # Re: 13 % de « code mort »
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: 13 % de « code mort »
Posté par Papey . Évalué à 9.
[^] # Re: 13 % de « code mort »
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
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...)
"La première sécurité est la liberté"
[^] # Re: 13 % de « code mort »
Posté par Papey . Évalué à 3.
Ariane ? (pas celle du club Dorothée)
[^] # Re: 13 % de « code mort »
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
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:
[^] # Re: 13 % de « code mort »
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: 13 % de « code mort »
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: 13 % de « code mort »
Posté par grafit . Évalué à 3.
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 (site web personnel) . Évalué à 4.
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 :
[^] # Re: 13 % de « code mort »
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
[^] # Re: 13 % de « code mort »
Posté par Sylvain Sauvage . Évalué à 3.
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
Posté par vic (site web personnel) . Évalué à 7.
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 (site web personnel) . Évalué à 4.
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ù ?
Posté par CdeMills . Évalué à 3.
Merci
CdM
[^] # Re: Oui, mais où ?
Posté par patrick_g (site web personnel) . Évalué à 4.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 5.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Polyspace
Posté par caspal . Évalué à 2.
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 . Évalué à 3.
# SWAT exempté?
Posté par GhZaaark3 . Évalué à 4.
[^] # Re: SWAT exempté?
Posté par CoinKoin . Évalué à 5.
[^] # d'ailleurs...
Posté par M . É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 . Évalué à 5.
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 . Évalué à 5.
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 (site web personnel) . Évalué à 0.
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).
# lien en français
Posté par j (site web personnel) . Évalué à 1.
[^] # publiés?
Posté par fakbill . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.