> Certains (cf. par ex. Sytoka Modon plus haut) semblent avoir mal
> compris pourquoi cette fonction peut utiliser de la mémoire non
> initialisée.
Désolé mais je n'ai pas du tout dis cela. J'ai dis que je n'y connaissais rien au fonctionnement interne. Moi ce qui me surprends en lisant les commentaires, c'est que ca a l'air vachement compliqué d'utilisé la bibliothèque OpenSSL puiqu'on retrouve cet appel a MD_Update() plusieurs fois dans le code. Si on veut du code sur, j'ai l'impression que le mieux est d'avoir une API simple ?
Comme tout le monde va de sa proposition et tu en fait des bonnes, j'y suis allé de la mienne sur un thème peu évoqué ici du contrôle par cas test /a posteriori/.
Le contrôle par cas test est à la charge du concepteur de l'application et permet de s'assurer, en plus des autres contrôles, une certaine stabilité de l'application, et cela de manière relativement automatique.
[^] # Re: Voici pourquoi openssl lit de la mémoire non initialisée (et ce n'
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 5.
> compris pourquoi cette fonction peut utiliser de la mémoire non
> initialisée.
Désolé mais je n'ai pas du tout dis cela. J'ai dis que je n'y connaissais rien au fonctionnement interne. Moi ce qui me surprends en lisant les commentaires, c'est que ca a l'air vachement compliqué d'utilisé la bibliothèque OpenSSL puiqu'on retrouve cet appel a MD_Update() plusieurs fois dans le code. Si on veut du code sur, j'ai l'impression que le mieux est d'avoir une API simple ?
Comme tout le monde va de sa proposition et tu en fait des bonnes, j'y suis allé de la mienne sur un thème peu évoqué ici du contrôle par cas test /a posteriori/.
Le contrôle par cas test est à la charge du concepteur de l'application et permet de s'assurer, en plus des autres contrôles, une certaine stabilité de l'application, et cela de manière relativement automatique.