> n'est-il pas moyen de créer un outil permettant d'auditer du code ?.
SWAT... (d'ailleur si tu lisais lkml ou hackers au lieu de troller ici et sur irc tu aurais deja remarque qu'ils postent assez regulierement les problèmes qu'ils trouvent).
Enfin croire qu'un tel outil va corriger tout les trous c'est croire au pere noel. Tu penses pas que si c'etait possible ca se saurait depuis tres longtemps et on serait tous au chomage.
Tu sais même sur les projets type spacial, avec de la preuve formelle sur de petit bout du code et du soft redondant (tu pars des memes specifications et tu as deux implementations) etc. on arrive encore a faire exploser des fusees. Alors penses tu pour un ouvrage de la taille d'une distrib.
De même a cours terme aucun outil ne te diras que tu as mal verifier la valeur de retour d'une fonction en C. Les excetions sont beaucoup moins casse geule de ce côte la...
On peut auditer automatiquement sur des choses plus ou moins triviales, en userland on peut facilement detecter les erreurs memoires, en kernel land on peut assez facilement detecter les erreurs de mutex. Pour le reste...
Pour tes grands conseils sur les devels en carton regarde du cote de FreeBSD. Le dernier adviso, syscons, si tu cherches qui a commis la bourde tu tombes sur ce commit : http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/syscons/syscons.c(...) regarde son auteur tu verras que c'est loin d'etre un con. L'erreur est humaine. De plus quelqu'un avait lu son patch puisque le commit d'apres est juste un s/0/NULL donc il n'avait pas vu le probleme non plus. Phk etait aussi passe sur le fichier 20 jours apres.... D'ailleur donne moi ton code je suis sur qu'en cherchant je trouve des choses sympas !
[^] # Re: Compétences des Kernels Hackers.
Posté par ckyl . En réponse au journal Linux c'est plein de trous. Évalué à 3.
SWAT... (d'ailleur si tu lisais lkml ou hackers au lieu de troller ici et sur irc tu aurais deja remarque qu'ils postent assez regulierement les problèmes qu'ils trouvent).
Enfin croire qu'un tel outil va corriger tout les trous c'est croire au pere noel. Tu penses pas que si c'etait possible ca se saurait depuis tres longtemps et on serait tous au chomage.
Tu sais même sur les projets type spacial, avec de la preuve formelle sur de petit bout du code et du soft redondant (tu pars des memes specifications et tu as deux implementations) etc. on arrive encore a faire exploser des fusees. Alors penses tu pour un ouvrage de la taille d'une distrib.
De même a cours terme aucun outil ne te diras que tu as mal verifier la valeur de retour d'une fonction en C. Les excetions sont beaucoup moins casse geule de ce côte la...
On peut auditer automatiquement sur des choses plus ou moins triviales, en userland on peut facilement detecter les erreurs memoires, en kernel land on peut assez facilement detecter les erreurs de mutex. Pour le reste...
Pour tes grands conseils sur les devels en carton regarde du cote de FreeBSD. Le dernier adviso, syscons, si tu cherches qui a commis la bourde tu tombes sur ce commit : http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/syscons/syscons.c(...) regarde son auteur tu verras que c'est loin d'etre un con. L'erreur est humaine. De plus quelqu'un avait lu son patch puisque le commit d'apres est juste un s/0/NULL donc il n'avait pas vu le probleme non plus. Phk etait aussi passe sur le fichier 20 jours apres.... D'ailleur donne moi ton code je suis sur qu'en cherchant je trouve des choses sympas !