En même temps beugler que le code est moche ça n'est ni très utile, ni très intéressant.
Si je vois quelque chose et que je peux le corriger, je le fais, si je ne peux pas j'ouvre un rapport de bug. À aucun moment je dis que je fais juste gueuler sur le code des autres, au contraire je suis plutôt silencieux. Ces expériences sont chaque fois liées à un patch n'apportant rien qu'une correction évitant des bugs triviaux.
Je ne vais pas te dire qui a tord et qui a raison, mais ça ne semble pas aussi évident que ce que tu avance.
J'ai corrigé un bout de code dans openldap, ça faisait planter le serveur dès qu'on envoyait une requête correctement formée, suivant le protocole, mais qui retournait pas de résultat. À partir du moment où l'authentification, et certainement d'autres services, s'arrêtent de fonctionner pour une requête correcte mais ne retournant pas de résultat, je penses que c'est évident que le retour doit être vérifié (il me semble, ça fait longtemps donc ma mémoire peut me tromper, qu'il n'y avait pas besoin d'être authentifié sur le serveur avant d'envoyer la requête).
Par contre si ta relecture consiste surtout à vérifier que les retours d'allocations sont vérifiés je te conseil d'investir (pas forcément financièrement) dans un analyseur statique de code ça permet d'être exhaustif plutôt que d'aller piocher quelques bouts de code au hasard.
Ma relecture est simplement dans un processus de sélection entre X ou Y. Quand j'arrive pas à me décider entre les deux, je prends un peu de code et si le code me plaît, dans un sens totalement subjectif, ben je vais préférer ce dernier. Si je vois un bug durant cette lecture, je le corrige ou le signal. Je n'ai pas le temps de faire de la relecture de code complète avec analyse statique, détection de fuites de mémoire, ...
Et j'aime lire du C, je ne vais pas m'en priver.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ne vas pas trop vite !
Posté par Etienne Bagnoud . En réponse au journal Sécurité de l'open source Vs closed source: MS14-066. Évalué à 7. Dernière modification le 18 novembre 2014 à 10:28.
Si je vois quelque chose et que je peux le corriger, je le fais, si je ne peux pas j'ouvre un rapport de bug. À aucun moment je dis que je fais juste gueuler sur le code des autres, au contraire je suis plutôt silencieux. Ces expériences sont chaque fois liées à un patch n'apportant rien qu'une correction évitant des bugs triviaux.
J'ai corrigé un bout de code dans openldap, ça faisait planter le serveur dès qu'on envoyait une requête correctement formée, suivant le protocole, mais qui retournait pas de résultat. À partir du moment où l'authentification, et certainement d'autres services, s'arrêtent de fonctionner pour une requête correcte mais ne retournant pas de résultat, je penses que c'est évident que le retour doit être vérifié (il me semble, ça fait longtemps donc ma mémoire peut me tromper, qu'il n'y avait pas besoin d'être authentifié sur le serveur avant d'envoyer la requête).
Ma relecture est simplement dans un processus de sélection entre X ou Y. Quand j'arrive pas à me décider entre les deux, je prends un peu de code et si le code me plaît, dans un sens totalement subjectif, ben je vais préférer ce dernier. Si je vois un bug durant cette lecture, je le corrige ou le signal. Je n'ai pas le temps de faire de la relecture de code complète avec analyse statique, détection de fuites de mémoire, ...
Et j'aime lire du C, je ne vais pas m'en priver.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell