Discussion :

[zizoufoot]

Bonjour,

Ma question est dans le titre de la discussion.

J'ai cherché du côté de méthodes permettant de connaître le nombre de caractères restant dans stdin, mais sans résultat..

NB : Il faut donc bannir toute solution consistant à vider tant que '\n' n'est pas lu.

Si vous avez une solution ou une piste, ça m'aiderait pas mal.

Merci

Edit :
La seule solution que j'ai actuellement trouvé(non portable) est de simuler l'appui d'un caractère de terminaison et de faire un _getch() tant que le caractère de terminaison n'est pas rencontré..
Ou encore la simulation d'une chaîne de caractère de terminaison. Mais ce sont des solutions approximatives et pouvant être sujettes à des erreurs.

[Obsidian]

Le problème vient du fait que stdin est « l'entrée standard » et que tu ne connais pas la nature de celle-ci à l'avance : tu ne peux pas savoir si ce que tu lis provient d'un fichier, d'un tube, d'un socket ou du clavier. Ça signifie que, dans ce dernier cas, tu ne peux pas savoir à l'avance si l'utilisateur a réellement fini d'entrer ses informations ou s'il va en ajouter d'autres quelques secondes plus tard.

Si ce que tu veux faire, par contre, c'est vider le buffer clavier à un moment donné et ne prendre en considération que ceux qui arriveront après (pour faire une saisie fiable), alors il faut passer en mode non-bloquant et lire les caractères jusqu'à ce que le tampon soit vide et que l'appel « échoue ». C'est possible mais c'est de la programmation système et ça ne fait pas partie de la norme C.

On en parlait ici.

[zizoufoot]

Merci pour ta réponse. Je vais regarder de ce côté là

[Bktero]

@Obsidian : ne serait-il pas temps de mettre à jour la FAQ à ce sujet ?

[zizoufoot]

Edit :
La seule solution que j'ai actuellement trouvé(non portable) est de simuler l'appui d'un caractère de terminaison et de faire un _getch() tant que le caractère de terminaison n'est pas rencontré..
Ou encore la simulation d'une chaîne de caractère de terminaison. Mais ce sont des solutions approximatives et pouvant être sujettes à des erreurs.

Petite question. Ma solution est-elle valable d'après vous ?

[ternel]

en effet, ce n'est pas une bonne situation, rien ne dit que tu parviennent à écrire au fond de stdin. surtout si c'est une socket, un fichier en lecture seule ou /dev/random

[zizoufoot]

en effet, ce n'est pas une bonne situation, rien ne dit que tu parviennent à écrire au fond de stdin. surtout si c'est une socket, un fichier en lecture seule ou /dev/random

Merci Du même avis.

[Obsidian]

@Obsidian : ne serait-il pas temps de mettre à jour la FAQ à ce sujet ?

Si, probablement, mais le sujet a l'air de diviser les opinions et je ne suis pas personnellement en charge de la FAQ. Il faudrait en parler aux personnes concernées.

[jabbounet]

un truc comme ça?

Code :

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

1
2
3
 
int   ch;
while ((ch = getchar()) != '\n' && ch != EOF);

[Obsidian]

un truc comme ça?

Code :

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

1
2
3
 
int   ch;
while ((ch = getchar()) != '\n' && ch != EOF);

Non, parce que ce n'est valable que sur un fichier. Si l'entrée standard est le clavier, par exemple, ta boucle bloquera. Et selon la discipline appliquée au terminal, taper une touche peut ne pas suffire à la débloquer : les caractères s'accumuleront du côté utilisateur jusqu'à ce qu'il appuie sur Return.

[Médinoc]

Je n'ai pas bien compris le but de la manœuvre. S'agit-il de faire des entrées non-bloquantes?

[Obsidian]

Je n'ai pas bien compris le but de la manœuvre. S'agit-il de faire des entrées non-bloquantes?

Oui. Mais faire cela relève de la programmation système et pas du C standard, malheureusement.

[Médinoc]

Oui, et dans ce cas, j'irais directement sur **curses, avec kbhit() et getch().

[Obsidian]

Oui, et dans ce cas, j'irais directement sur **curses, avec kbhit() et getch().

C'est vrai mais c'est toujours la même chose : ce n'est pas une manière fiable de vider le buffer d'entrée quelque soit ce qu'il contient.

[jabbounet]

ou alors un bon vieux read.

man read:
Name
read - read from a file descriptor
Synopsis

#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);

Description
read() attempts to read up to count bytes from file descriptor fd into the buffer starting at buf.

On files that support seeking, the read operation commences at the current file offset, and the file offset is incremented by the number of bytes read. If the current file offset is at or past the end of file, no bytes are read, and read() returns zero.

If count is zero, read() may detect the errors described below. In the absence of any errors, or if read() does not check for errors, a read() with a count of 0 returns zero and has no other effects.

If count is greater than SSIZE_MAX, the result is unspecified.

Return Value
On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. On error, -1 is returned, and errno is set appropriately. In this case it is left unspecified whether the file position (if any) changes.

[zizoufoot]

ou alors un bon vieux read.

Si count dépasse le nombre de caractères dans stdin, read attend l'ajout de nouveau caractères.