Langage C : cours + exercices corrigés + TPs + exams

manianis a écrit:Aussi, les problèmes d'allocations et de libération de mémoire ne sont pas toujours la faute du programmeur mais aussi peuvent provenir d'une faute de conception.

C'est peu probable. Les compilateurs conformes sont rarement sujets à des bugs. Si je me souviens bien, une étude dit que, quand un programme a un bug, il n'y a que 5% de risques que cela provienne du compilateur.
A partir de là, on peut totalement faire confiance aux fonctions d'allocation mémoire à partir du moment où on n'oublie pas de vérifier leur retour.

manianis a écrit:Oui, justement, c'est trés simple à dire mais les exceptions sont multiples. Les bugs font que parfois des fonctions standard ne réagissent pas de la manière attendue et qu'il génèrent des problèmes de mémoire.

Je crois comprendre ce que vous vouliez dire : lorsqu'on passe des paramètres que la fonction ne "s'attend" pas à avoir, elle peut planter (ou faire autre chose).
C'est normal, c'est un comportement indéterminé défini par la norme. En effet, les implémenteurs de compilateurs ne sont pas obligés de gérer les cas comme fopen(NULL, NULL), malloc(0), strlen(NULL), isdigit(-20) (sauf si EOF = -20), etc.
En appliquant les principes de la programmation défensive, on arrive assez facilement à éviter ce genre de cas.

Timon:
à votre avis, pourquoi fopen(NULL, NULL)n'est pas géré par certains compilateurs? Peut-tu présenter en quelques mots la programmation défensive?

nabiL a écrit:Timon:
à votre avis, pourquoi fopen(NULL, NULL)n'est pas géré par certains compilateurs?

C'est simple : on demande à ouvrir "rien" en mode "rien". Ca n'a absolument aucun sens.
Comme les fonctions standard sont beaucoup utilisées, le Comité a décidé de ne pas forcer les implémenteurs de vérifier les paramètres. Cela permet à long terme une augmentation des performances.
fopen() tente alors de déréférencer ses paramètres qui sont NULL. Le déréférencement de NULL provoquant un comportement indéterminé, la stabilité du programme n'est plus.

Peut-tu présenter en quelques mots la programmation défensive?

Elle consiste à vérifier que chaque donnée est, à tout instant, parfaitement contrôlée et que le programme est capable de réagir face à n'importe quelle situation étrange.

Merci pour la réponse Timon.
En fait, que veut dire exactement :

En effet, les implémenteurs de compilateurs ne sont pas obligés de gérer les cas comme fopen(NULL, NULL), malloc(0),

Il y a les codes retour non? 0 si aucune erreur sinon le code de l'erreur.
C'est vrai il y a des fonctions qui retournent des valeurs entières non nulles par exemple "descripteur d'un fichier" ... dans ce cas, il faut gérer les erreurs autrement à mon avis.
J'espère que je me suis bien exprimé (je ne suis pas informaticien )

Timon :
Si les valeurs passées aux dites fonctions possèdent un type correct ou un type qui lui est compatible alors la ce n'est pas la tache du compilateur de vérifier la validité de ces valeurs.

Il n'est pas logique de faire des appels du type fopen(NULL, NULL). Le programmeur a commis une faute de conception. Je ne sais pas si peut être dé-référencer mais je sais qu'il a été déclaré comme un define. Et à ce que je sais il faudra pour le redéfinir faire appel à undef.

manianis a écrit:Timon :
Si les valeurs passées aux dites fonctions possèdent un type correct ou un type qui lui est compatible alors la ce n'est pas la tache du compilateur de vérifier la validité de ces valeurs.

Il n'est pas logique de faire des appels du type fopen(NULL, NULL). Le programmeur a commis une faute de conception. Je ne sais pas si peut être dé-référencer mais je sais qu'il a été déclaré comme un define. Et à ce que je sais il faudra pour le redéfinir faire appel à undef.

Je n'ai pas bien saisi

methodiX a écrit:Il y a les codes retour non? 0 si aucune erreur sinon le code de l'erreur.

Il y a des codes d'erreurs mais ils ne traitent pas forcément tous les cas. Prenons strtol() :
Si on écrit strtol(s_chaine, NULL, 10) avec s_chaine, chaîne valide, quelque soit son contenu, son comportement est parfaitement défini et LONG_MIN, LONG_MAX et 0 peuvent plus ou moins servir de codes d'erreur.
Si s_chaine est NULL, il n'y a pas de code d'erreur, seulement un comportement indéterminé.

C'est vrai il y a des fonctions qui retournent des valeurs entières non nulles par exemple "descripteur d'un fichier" ... dans ce cas, il faut gérer les erreurs autrement à mon avis.

Ces fonctions renvoient -1 en cas d'erreur sauf paramètre NULL.

manianis a écrit:Il n'est pas logique de faire des appels du type fopen(NULL, NULL). Le programmeur a commis une faute de conception.

En effet mais ça peut arriver et on doit bien savoir ce qu'il passera dans ce cas : à savoir, n'importe quoi.

Je ne sais pas si peut être dé-référencer mais je sais qu'il a été déclaré comme un define. Et à ce que je sais il faudra pour le redéfinir faire appel à undef.

Que voulez-vous dire ?

Timon: Je ne sais pas si NULL peut être dé-référencé mais je sais qu'il a été
déclaré comme un define. Et à ce que je sais il faudra pour le
redéfinir faire appel à undef.

methodiX: les fichiers #include sont appelées des fichiers d'entêtes et elles contiennent uniquement des prototypes de fonctions (càd la déclaration de la fonction sans implémentation). Ces prototypes servent à déterminer le type des arguments passées à une fonction. Et elles permettent au compilateur de déterminer si l'utilisateur a passé les bons arguments.

manianis a écrit:Timon: Je ne sais pas si NULL peut être dé-référencé mais je sais qu'il a été
déclaré comme un define. Et à ce que je sais il faudra pour le
redéfinir faire appel à undef.

Quel serait l'intérêt à la redéfinir avec la directive #define ? D'ailleurs, il me semble que la norme indique bien que la redéfinition des macros standard n'est pas légale.

manianis a écrit:methodiX: les fichiers #include sont appelées des fichiers d'entêtes et elles contiennent uniquement des prototypes de fonctions (càd la déclaration de la fonction sans implémentation). Ces prototypes servent à déterminer le type des arguments passées à une fonction. Et elles permettent au compilateur de déterminer si l'utilisateur a passé les bons arguments.

Petites précisions si ça ne te dérange pas.
Il est vrai que, dans la majorité des cas, les fichiers inclus sont des fichiers d'en-tête mais ce n'est pas forcément le cas.
Il est possible d'inclure un fichier-source mais c'est, bien entendu, à proscrire.
On peut aussi se servir de cette directive pour inclure des items-lists.
Ensuite, un fichier d'en-tête ne fait pas, heureusement, que déclarer des fonctions publiques. Il donne aussi accès à des macros (macro-constantes et macro-fonctions), des variables globales publiques et des déclarations (avec peut-être la définition) de structures.
En C99, on peut aussi y trouver des fonctions cette fois-ci définies dites inline. Cependant, ayant toujours préféré me restreindre au C89, je ne saurais expliquer le pourquoi de cette nouveauté.

Timon a écrit:

manianis a écrit:methodiX: les fichiers #include sont appelées des fichiers d'entêtes et elles contiennent uniquement des prototypes de fonctions (càd la déclaration de la fonction sans implémentation). Ces prototypes servent à déterminer le type des arguments passées à une fonction. Et elles permettent au compilateur de déterminer si l'utilisateur a passé les bons arguments.

Petites précisions si ça ne te dérange pas.
Il est vrai que, dans la majorité des cas, les fichiers inclus sont des fichiers d'en-tête mais ce n'est pas forcément le cas.
Il est possible d'inclure un fichier-source mais c'est, bien entendu, à proscrire.
On peut aussi se servir de cette directive pour inclure des items-lists.
Ensuite, un fichier d'en-tête ne fait pas, heureusement, que déclarer des fonctions publiques. Il donne aussi accès à des macros (macro-constantes et macro-fonctions), des variables globales publiques et des déclarations (avec peut-être la définition) de structures.
En C99, on peut aussi y trouver des fonctions cette fois-ci définies dites inline. Cependant, ayant toujours préféré me restreindre au C89, je ne saurais expliquer le pourquoi de cette nouveauté.

Oui Timon vous avez raison j'ai uniquement cité un parmi les usages qu'on pourra faire des fichiers include.

manianis a écrit:Oui Timon vous avez raison j'ai uniquement cité un parmi les usages qu'on pourra faire des fichiers include.

Dans ce cas, pas de problème. Vous aviez utilisé le mot uniquement et j'ai eu peur que ce soit mal interprété.