Je ne sais pas ce que tu souhaites programmer et je sais bien qu'on ne peut pas toujours se passer du C, mais une chose est sûre : le C (et tous ses dérivés dont le C++) est un langage catastrophique au niveau de la robustesse et de la sécurité de programmation. Même en étant extrêmement rigoureux, on n'est jamais complètement à l'abri des nombreux problèmes "intrinsèques" au langage.
Je ne dis pas ça parce que je n'aime pas le C. Je programme presque exclusivement en C++, mais c'est justement cette expérience-là qui me fait dire : aucun programme écrit en C n'est robuste ou sécurisé. Il y a trop de failles intrinsèques au langage lui-même.
Je suis loin d'être un expert dans le domaine, mais voilà une petite recette personnelle pour éviter une grande partie des problèmes classiques :
* n'utilise aucun pointeur C. Elimine les * partout où c'est possible.
* ne gère jamais la mémoire toi-même.
* bannis toutes les fonctions d'entrée/sortie standards du C (genre printf)
* n'utilise jamais de tableaux en C.
C'est sûr. Quand on s'interdit tout ça, on se demande à quoi bon rester en C. Disons que ça doit servir de signal d'alerte. Dès qu'il y a une * ou des [ ] dans un code, il faut se poser la question de tous les cas particuliers. Une solution intermédiaire minimale, c'est d'utiliser une bibliothèque externe pour toutes ces notions.
Mais bon, ça reste des rustines collées sur un langage non fiable. Le fameux "bufferoverflow ", qui est le vice profond du C, est à l'origine de sans doute 95% des failles des logiciels actuels. Le C a été inventé à une époque où l'idée de robustesse n'avait pas encore percé. Conséquence : la sécurité en langage C est tout simplement une chimère.
La seule raison pour laquelle on reste sous ce langage, c'est la grande base de code existant, et le grand nombre de bibliothèques disponibles. Heureusement, ça change petit à petit. De moins en moins de programmeurs savent ce qu'est un pointeur, ni même ce que le terme de "gestion de la mémoire" peut signifier. Et je m'en réjouis.
Ah oui, juste pour la petite note : les outils comme valgrind sont très bons pour détecter certains types de problèmes précis, mais ils ne remplaceront jamais l'analyse détaillée par le programmeur de tous les cas particulier de son code. ça implique notamment de vérifier toutes les possibilités de pointeur qui ne sont pas à jour, de division par zéro, d'indice incorrect dans un tableau, etc. Une bonne pratique est de mettre des vérifications dans le code lui-même (par exemple sur tous les indices de tableau). Le gros piège, c'est de se dire : ah mais y'a de problème. L'indice est toujours inférieur à telle valeur parce que gnagnagna. Il vaut mieux mettre un bon gros test if sur l'indice pour être certain qu'il se comporte comme prévu.
D'ailleurs le problème de fond de la robustesse/sécurité, à mon avis, n'est pas de savoir quoi faire, mais de savoir si on est prêt à le faire : le coût à payer en temps supplémentaire de codage et en pollution du code est très élevé pour sécuriser vraiment un programme en C.
# Change de langage
Posté par grognon . En réponse au journal Programmation robuste. Évalué à 2.
Je ne dis pas ça parce que je n'aime pas le C. Je programme presque exclusivement en C++, mais c'est justement cette expérience-là qui me fait dire : aucun programme écrit en C n'est robuste ou sécurisé. Il y a trop de failles intrinsèques au langage lui-même.
Je suis loin d'être un expert dans le domaine, mais voilà une petite recette personnelle pour éviter une grande partie des problèmes classiques :
* n'utilise aucun pointeur C. Elimine les * partout où c'est possible.
* ne gère jamais la mémoire toi-même.
* bannis toutes les fonctions d'entrée/sortie standards du C (genre printf)
* n'utilise jamais de tableaux en C.
C'est sûr. Quand on s'interdit tout ça, on se demande à quoi bon rester en C. Disons que ça doit servir de signal d'alerte. Dès qu'il y a une * ou des [ ] dans un code, il faut se poser la question de tous les cas particuliers. Une solution intermédiaire minimale, c'est d'utiliser une bibliothèque externe pour toutes ces notions.
Mais bon, ça reste des rustines collées sur un langage non fiable. Le fameux "bufferoverflow ", qui est le vice profond du C, est à l'origine de sans doute 95% des failles des logiciels actuels. Le C a été inventé à une époque où l'idée de robustesse n'avait pas encore percé. Conséquence : la sécurité en langage C est tout simplement une chimère.
La seule raison pour laquelle on reste sous ce langage, c'est la grande base de code existant, et le grand nombre de bibliothèques disponibles. Heureusement, ça change petit à petit. De moins en moins de programmeurs savent ce qu'est un pointeur, ni même ce que le terme de "gestion de la mémoire" peut signifier. Et je m'en réjouis.
Ah oui, juste pour la petite note : les outils comme valgrind sont très bons pour détecter certains types de problèmes précis, mais ils ne remplaceront jamais l'analyse détaillée par le programmeur de tous les cas particulier de son code. ça implique notamment de vérifier toutes les possibilités de pointeur qui ne sont pas à jour, de division par zéro, d'indice incorrect dans un tableau, etc. Une bonne pratique est de mettre des vérifications dans le code lui-même (par exemple sur tous les indices de tableau). Le gros piège, c'est de se dire : ah mais y'a de problème. L'indice est toujours inférieur à telle valeur parce que gnagnagna. Il vaut mieux mettre un bon gros test if sur l'indice pour être certain qu'il se comporte comme prévu.
D'ailleurs le problème de fond de la robustesse/sécurité, à mon avis, n'est pas de savoir quoi faire, mais de savoir si on est prêt à le faire : le coût à payer en temps supplémentaire de codage et en pollution du code est très élevé pour sécuriser vraiment un programme en C.