demande de precision

**lastrecrue** · 28/09/2006, 01h24

sur la faq du C je trouve ça

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 */

je ne comprend pas très bien que vas faire cette fonction, ce qui me surprend c'est le ; après le while sans instruction.

**Nasky** · 28/09/2006, 03h25

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) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int c;
while ((c = getchar()) != '\n' && c != EOF)
{
}

Nas'

**Trap D** · 28/09/2006, 08h39

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.

**InOCamlWeTrust** · 28/09/2006, 21h31

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.

**Trap D** · 28/09/2006, 22h24

Envoyé par InOCamlWeTrust

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.

**lastrecrue** · 29/09/2006, 00h43

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.

**Nasky** · 29/09/2006, 01h14

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'

**lastrecrue** · 29/09/2006, 03h28

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <stdio.h>
#include <conio.h>
void main()
{
char *s;
int i=-1;
clrscr();
while(s[i]!=10)
{
<div style="margin-left:40px">i++;</div><div style="margin-left:40px">s[i]=getchar();</div>}
printf("%s",s);
getch();
}

**Emmanuel Delahaye** · 29/09/2006, 08h19

Envoyé par lastrecrue

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.

Dés que tu commences à programmer pour de vrai et que ton code est testé dans des conditions réelles.

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...

**InOCamlWeTrust** · 29/09/2006, 11h49

Envoyé par Trap D

Ah ben non, surtout pas de gets, mais un fgets, gets est un BUG connu du C.

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.

**Médinoc** · 29/09/2006, 11h51

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.

**Emmanuel Delahaye** · 29/09/2006, 11h57

Envoyé par InOCamlWeTrust

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.

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.

**InOCamlWeTrust** · 29/09/2006, 12h45

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 !

**Médinoc** · 29/09/2006, 12h53

Mais quand on fait un read(), on peut spécifier une taille de buffer...

**Emmanuel Delahaye** · 29/09/2006, 13h00

Envoyé par InOCamlWeTrust

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.

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.

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.

Ca n'a donc rien à voir.

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 !

Be my guest !

http://emmanuel-delahaye.developpez.com/inputs.htm

**InOCamlWeTrust** · 29/09/2006, 13h07

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 !

**Emmanuel Delahaye** · 29/09/2006, 13h15

Envoyé par InOCamlWeTrust

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...)

**InOCamlWeTrust** · 29/09/2006, 13h23

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.

demande de precision

C

Discussions similaires

Partager

Partager