Version imprimable
sur la faq du C je trouve çaje ne comprend pas très bien que vas faire cette fonction, ce qui me surprend c'est le ; après le while sans instruction.Citation:
Comment vider le buffer clavier ? [haut]
auteurs :Haypo, LFE, Emmanuel Delahaye, gl
La méthode la plus sûre pour vider le buffer clavier consiste à consommer tout les caractères présents dans ce buffer jusqu'à ce qu'il soit vide :
#include <stdio.h>
int c;
while ((c = getchar()) != '\n' && c != EOF); /* mange le tampon */
Ce code permet de vider l'entrée standard. getchar() permet de lire caractère par caractère l'entrée donc on lit tous les caractères jusqu'à avoir le '\n' ou un EOF.
Le point virgule veut dire qu'on ne fait pas de traitement à chaque itération. En effet, on lit le caractère avec getchar() donc on le "sort" de l'entrée. On n'a pas besoin de faire autre chose. Donc le code peut s'écrire aussi (et c'est peut-être mieux) :
Nas'Code:
2
3
4
Qu'est-ce que je veux faire ? Vider le tampon clavier, c'est-à-dire le lire jusqu'à rencontrer '\n' ou EOF.
Donc, tant que ce que je lis dans le tampon clavier n'est pas un retour chariot ou EOF, je ne fais rien, je boucle.
Ce genre de code, comme dit plus haut, permet de consommer tous les caractères qui te seront inutiles par la suite et qui sont potentiellement parasites pour des entrées (lectures sur l'entrée standard) futures.
Par exemple, supposons que tu veuilles lire un nombre puis une chaîne de caractères. Lors de la saisie, si tu entres deux nombres au lieu d'un seul comme attendu, tu te retrouveras, lors de la lecture de la chaîne de caractères, avec le deuxième nombre non lu qui est en réalité un parasite.
Voilà, ça sert à ça vider le buffer de temps en temps.
Le plus sûr reste encore de faire un gets puis de lire la chaîne avec un sscanf... comme ça, au moins, il n'y a pas d'ambigüité possible.
Ah ben non, surtout pas de gets, mais un fgets, gets est un BUG connu du C.Citation:
Envoyé par InOCamlWeTrust
je ne comprend pas trop un truc même si j'ai déjà lu quelque document dessus, parmi sur le site de emanuel, on nous apprend a la fac le C avec printf scanf, après sur les forum de developpez, je trouve toujours cette remarque sur les bug de scanf et de gets, je suis en licence cette année on a fais un peut de théorie de langage structure de donnée toujours avec le C et toujours j'ai utiliser scanf et j'arrive e m'en sortir avec, ma question est : a quel niveau de la programmation je vais resentir la nécessité de fgets.
Le truc c'est que tes programmes ne sont utilisés que par toi et donc lors d'une saisie, tu l'effectues correctement. Si tu veux un nombre, tu mets un nombre, si tu veux une chaine de 10 caractères, tu entres une chaine de la bonne taille, etc. Mais on sait tous que l'erreur est humaine et que par conséquent, c'est au programmeur de gérer les erreurs de l'utilisateur. Donc c'est au programmeur d'écrire le code le plus sécurisé possible pour éviter les failles et plantages du programme.
Donc je dirais que tu dois dès le début prendre de bonnes habitudes. Mais tu ressens vraiment la nécessité de le faire seulement quand tu donneras ton programme à quelqu'un qui, sans le vouloir, le fera planter ;)
Nas'
je pense faire une fonction qui fais un petits peut le même travail que gets mais qui ne lis que les saisi clavier. est ce la penne que je continu dans ce sens?Code:
2
3
4
5
6
7
8
9
10
11
12
13
Dés que tu commences à programmer pour de vrai et que ton code est testé dans des conditions réelles.Citation:
Envoyé par lastrecrue
La vraie question est plutôt "à partir de quand serais-je assez bon pour pouvoir ecrire un programme utilisant scanf() résistant au test du singe".
Pour te donner une idée : http://xrenault.developpez.com/tutoriels/c/scanf/
Have fun...
Pourquoi dis-tu qu'il s'agit d'un bug : est-ce dû au comportements divers de la fonction selon le type d'implantation ? Dans ce cas, ce n'est pas un bug du langage à proprement parler, mais un comportement stupide ou étrange de telle ou telle implantation.Citation:
Envoyé par Trap D
Non, c'est du au fait que cette fonction ait 99% de chances de faire un buffer overflow au test du singe, quelle que soit l'implémentation.
Les rares cas où elle ne fait pas de débordement de tampon, c'est quand le singe appuie sur Entrée trop tôt.
C'est un bug de conception de la fonction (pas d'indication de la taille du buffer de récéption). Comme elle fait partie de la bibliothèque standard, elle fait partie intégrante du langage C. C'est donc bien un bug du langage C.Citation:
Envoyé par InOCamlWeTrust
Oui, maintenant que j'ai la signature de la fonction sous les yeux et sa man-page je vois ce que tu veux dire.
Je ne pense pas que l'on puisse appeler celà un bug, mais plutôt un comportement indapaté à une situation qui, elle, peut-être assez imprévisible.
C'est comme faire un read sur un buffer trop petit... est-ce un bug de la fonction read ? Non, juste une erreur d'utilisation de la fonction.
La démarche la plus propre me paraît encore de devoir se définir soi-même une fonction plus robuste à de telles erreurs... ça ne coûte pas grand chose mais ça peut éviter grand nombre de désagréments !
Mais quand on fait un read(), on peut spécifier une taille de buffer...
Il n'y a aucun moyen portable de se prémunir contre ça. C'est un bug de conception qui induit un bug de comportement potentiel. C'est interdit en programmation industrielle. Le comportement doit être déterministe.Citation:
Envoyé par InOCamlWeTrust
Ca n'a donc rien à voir.Citation:
C'est comme faire un read sur un buffer trop petit... est-ce un bug de la fonction read ? Non, juste une erreur d'utilisation de la fonction.
Be my guest !Citation:
La démarche la plus propre me paraît encore de devoir se définir soi-même une fonction plus robuste à de telles erreurs... ça ne coûte pas grand chose mais ça peut éviter grand nombre de désagréments !
http://emmanuel-delahaye.developpez.com/inputs.htm
La seule chose que je voulais dire, c'est qu'il ne faut pas aborder le C de la même façon que l'on aborderait d'autres langages : le C laisse à la charge du programmeur beaucoup plus de choses que d'autres langages. Si le programmeur n'a donc pas envie de se plier à ces contraintes, c'est sûr qu'un joue ou l'autre ça foire !
C'est comme celui qui veut faire de l'assembleur : il doit prendre des précautions évidentes... sinon les dégats peuvent être importants !
Tu as tout compris. Certains considèrent le C comme un 'assembleur portable'. C'est presque vrai (la bibliothèque en plus...)Citation:
Envoyé par InOCamlWeTrust
Je n'irais pas jusqu'à dire que le C est un assembleur portable : en effet, la norme ANSI donne peu de garanties quant aux opérations de bas niveau, comme les casts entre pointeurs sur types différents, les casts sur les fonctions de types différents ou encore les conversions entier<->pointeur...
Cependant, il est aussi possible, une fois les routines critiques implantées de façon robuste, de s'abstraire du matériel et/ou de la mémoire. En tout cas, c'est l'impression que j'en ai.