Il est communément admis que l'appel de getchar() suspend l'exécution du
programme jusqu'à détection d'un '\n'. Or je n'ai pas vu de description de ce
comportement dans la norme. Je me demandais si c'était simplement un
comportent 'courant' des systèmes et si l'appui de la touche 'enter' était
une obligation.
Merci de m'avoir lu.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jz
Emmanuel Delahaye wrote:
Bonjour,
Il est communément admis que l'appel de getchar() suspend l'exécution du programme jusqu'à détection d'un 'n'. Or je n'ai pas vu de description de ce comportement dans la norme. Je me demandais si c'était simplement un comportent 'courant' des systèmes et si l'appui de la touche 'enter' était une obligation.
Ce n'est pas getchar() qui coince, mais le clavier qui garde tout pour lui jusqu'au 'n', *quand stdin n'est pas redirigé*. Tu n'as qu'à essayer de lire avec getchar() en redirigeant l'entrée standard vers un fichier.
Je m'étonne que tu poses cette question, toi qui étais outré d'une telle confusion ici même, dans le fil "scanf & puts" du 17/01.
C'est le petit troll du week-end ?
Merci de m'avoir lu.
Ce fut un plaisir :)
Jacques
Emmanuel Delahaye wrote:
Bonjour,
Il est communément admis que l'appel de getchar() suspend l'exécution du
programme jusqu'à détection d'un 'n'. Or je n'ai pas vu de description de ce
comportement dans la norme. Je me demandais si c'était simplement un
comportent 'courant' des systèmes et si l'appui de la touche 'enter' était
une obligation.
Ce n'est pas getchar() qui coince, mais le clavier qui garde tout pour
lui jusqu'au 'n', *quand stdin n'est pas redirigé*. Tu n'as qu'à
essayer de lire avec getchar() en redirigeant l'entrée standard vers un
fichier.
Je m'étonne que tu poses cette question, toi qui étais outré d'une telle
confusion ici même, dans le fil "scanf & puts" du 17/01.
Il est communément admis que l'appel de getchar() suspend l'exécution du programme jusqu'à détection d'un 'n'. Or je n'ai pas vu de description de ce comportement dans la norme. Je me demandais si c'était simplement un comportent 'courant' des systèmes et si l'appui de la touche 'enter' était une obligation.
Ce n'est pas getchar() qui coince, mais le clavier qui garde tout pour lui jusqu'au 'n', *quand stdin n'est pas redirigé*. Tu n'as qu'à essayer de lire avec getchar() en redirigeant l'entrée standard vers un fichier.
Je m'étonne que tu poses cette question, toi qui étais outré d'une telle confusion ici même, dans le fil "scanf & puts" du 17/01.
C'est le petit troll du week-end ?
Merci de m'avoir lu.
Ce fut un plaisir :)
Jacques
Randolf Carter
Ce n'est pas getchar() qui coince, mais le clavier qui garde tout pour lui jusqu'au 'n', *quand stdin n'est pas redirigé*. Tu n'as qu'à essayer de lire avec getchar() en redirigeant l'entrée standard vers un
fichier.
Oui, je dirai que ce comportement ne devrait pas faire parti de la norme car dépendant du stream derrière stdin. Et d'ailleurs je pense que même si stdin est sur le clavier, le comportement est déterminé par l'OS lui même. Sur Unix par exemple il est assez facile de supprimer cet aspect en changeant quelques paramêtres du terminal (tcsetattr).
-- - Randolf
Ce n'est pas getchar() qui coince, mais le clavier qui garde tout pour
lui jusqu'au 'n', *quand stdin n'est pas redirigé*. Tu n'as qu'à
essayer de lire avec getchar() en redirigeant l'entrée standard vers
un
fichier.
Oui, je dirai que ce comportement ne devrait pas faire parti de la norme
car dépendant du stream derrière stdin. Et d'ailleurs je pense que même
si stdin est sur le clavier, le comportement est déterminé par l'OS lui
même. Sur Unix par exemple il est assez facile de supprimer cet aspect
en changeant quelques paramêtres du terminal (tcsetattr).
Ce n'est pas getchar() qui coince, mais le clavier qui garde tout pour lui jusqu'au 'n', *quand stdin n'est pas redirigé*. Tu n'as qu'à essayer de lire avec getchar() en redirigeant l'entrée standard vers un
fichier.
Oui, je dirai que ce comportement ne devrait pas faire parti de la norme car dépendant du stream derrière stdin. Et d'ailleurs je pense que même si stdin est sur le clavier, le comportement est déterminé par l'OS lui même. Sur Unix par exemple il est assez facile de supprimer cet aspect en changeant quelques paramêtres du terminal (tcsetattr).
