Dans quelle proportion la correction d'une faille impose la modification de l'API ? Bien sûr ce cas peut exister mais il doit être relativement rare je pense.
Ding. Perdu. Ca arrive fréquemment en fait ! On se rend compte que la seule manière de bien corriger une faille, c'est d'ajouter un argument a une fonction; par exemple une méthode qui prend une grosse structure, et on se rend compte que la seule manière de pas se faire avoir par un buffer overflow, c'est de passer en argument la taille de la dite structure ... et blam, API cassée.
Alors oui je sais, chez les Bisounours, on pense directement à toutes les failles possibles et à passer tous les paramètres qu'il faut dès le début. Mais dans le monde réel, personne ne fait le design parfait dès le premier jet.
Tiens, d'ailleurs faudrait demander à Linus pourquoi il s'est fait chier à écrire Freax, Linux 0.x, Linux 1.x, Linux 2.0.x etc ..... il aurait pu faire Linux 2.6 directement en 1991, on aurait eu moins de problèmes quand même, l'API aurait changé moins souvent ;)
[^] # Re: Euh...
Posté par Gilles Gagniard . En réponse au journal Les drivers : c'est bien là le réel problème. Évalué à 4.
Ding. Perdu. Ca arrive fréquemment en fait ! On se rend compte que la seule manière de bien corriger une faille, c'est d'ajouter un argument a une fonction; par exemple une méthode qui prend une grosse structure, et on se rend compte que la seule manière de pas se faire avoir par un buffer overflow, c'est de passer en argument la taille de la dite structure ... et blam, API cassée.
Alors oui je sais, chez les Bisounours, on pense directement à toutes les failles possibles et à passer tous les paramètres qu'il faut dès le début. Mais dans le monde réel, personne ne fait le design parfait dès le premier jet.
Tiens, d'ailleurs faudrait demander à Linus pourquoi il s'est fait chier à écrire Freax, Linux 0.x, Linux 1.x, Linux 2.0.x etc ..... il aurait pu faire Linux 2.6 directement en 1991, on aurait eu moins de problèmes quand même, l'API aurait changé moins souvent ;)