Probleme de EOF

Bonjour, je suis actuellement en train d’apprendre le langage C en utilisant le livre Language C (K&R).

Je bloque déjà sur un problème certainement assez simple :

Je cherche à afficher le nombre de caractère d’entré en sortie en utilisant une simple incrémentation :

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <stdio.h> int main() { printf("Please enter a sentence:"); long nc; nc=0; while(getchar()!=EOF) ++nc; printf("number of character: %ld\n",nc); }

---

Malheureusement, ce code ne marche pas. Je pense que le problème vient de EOF qui me sort de la boucle. En faisant des recherches, J’ai trouvé un autre code qui fonctionne très bien :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#include <stdio.h> #include <stdlib.h>   int main(void){   printf("Please enter a sentence:"); fflush(stdout); char c; int nc=0; c=getchar(); while (c !='\n') { nc++; c=getchar(); } printf("number of character: %d\n",nc); return EXIT_SUCCESS;

---

Sur ce programme la condition sur la boucle est ‘\n’ au lieux de EOF. J’ai donc essayer de remplacer cette condition dans le premier programme et vice versa ce qui résolve mon problème.

Quelqu’un serait-il en mesure de m’expliquer pourquoi la condition de EOF ne marche pas dans ces programmes ?

Dans le livre de K&R ils utilisent EOF donc cela doit marcher =).

Merci pour votre aide.

Quel est ton symptome?
Que signifie conctrement ton "ca ne marche pas"?

Sais-tu que sous linux, tu peux faire CTRL+D pour provoquer une fin de fichier?
Dans mon souvenir, l'équivalent pour windows devrait être CTRL+Z.

EOF n'est pas la fin d'une ligne, mais la fin du flux, ou pour être parfaitement littéral, la "fin du fichier" (end of file).
Appuyer sur la touche <entrée> ne provoque pas une telle fin de fichier.

Bonjour,

Citation:

---

Que signifie conctrement ton "ca ne marche pas"?

---

Lorsque je tape entrée en executant le programme avec une phrase rien ne s'affiche.

Il semble que lorsque j'utilise EOF dans ma boucle le printf ne s'affiche pas car en bidouillant j'ai pu verifier que l'incrementation marchait correctement.

Pourquoi le printf s'affiche en remplacant EOF par '\n' je ne comprends pas.

Merci

Je comprends bien que EOF c'est la fin de fichier.

Ce que je ne comprends pas c'est qu'il m'affiche le printf si je limite ma boucle quand il rencontre une fin de ligne ('\n') mais pas si je lui limite la boucle avec la fin de fichier (EOF).

Est-ce que la lecture du EOF a l'intérieur de la boucle déclenche automatiquement la fin de l'exécution? (cela me semblerai surprenant vu que je test la boucle sur une valeur différente de EOF)


Dans ce cas-là, comment je px afficher mon résultat sur le nombre de caractère nc?

Quand tu demande la fin de fichier, il compte tant qu'il n'y a pas de fin de fichier.

Dans la console, il n'y en a que lorsque tu fais une manipulation précise.

Essaye ton programme avec une redirection d'un fichier existant:

programme < fichier.txt

on pourrait aussi citer le fameux heredocument assez explicite :

Code:

---

1 2 3 4 5 6

$ wc -c <<EOF > 123 > 456 > 789 > EOF 12

---

Citation:

---

Envoyé par brunounours1

Ce que je ne comprends pas c'est qu'il m'affiche le printf si je limite ma boucle quand il rencontre une fin de ligne ('\n') mais pas si je lui limite la boucle avec la fin de fichier (EOF).

---

Parce que le caractère '\n' permet de vider le tampon d'écriture :mrgreen: Cela dépend de pleins de paramètres, mais en théorie c'est un des moyens de le faire (fflush)

ISO C99 section 7.19.3/3:

Citation:

---

When a stream is unbuffered, characters are intended to appear from the source or at the destination as soon as possible. Otherwise characters may be accumulated and transmitted to or from the host environment as a block.

When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled.

When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered.

Furthermore, characters are intended to be transmitted as a block to the host environment when a buffer is filled, when input is requested on an unbuffered stream, or when input is requested on a line buffered stream that requires the transmission of characters from the host environment.

Support for these characteristics is implementation-defined, and may be affected via the setbuf and setvbuf functions.

---

Et en théorie, à la fin de ton programme tout doit être écrit dans ta fenêtre :mrgreen:

Citation:

---

Envoyé par brunounours1

Je comprends bien que EOF c'est la fin de fichier.

---

Bonjour
EOF ce n'est pas la fin de fichier. Prends n'importe quel ficher texte, tu verras qu'il se termine d'une façon ou d'une autre mais jamais par EOF.

EOF c'est une valeur spéciale (qui vaut pour l'instant -1) que renvoie la fonction de lecture quand elle ne peut plus lire le fichier parce qu'elle a atteint sa fin. Ce n'est pas la même chose.

Et pour info, ton premier code fonctionne parfaitement...

Merci pour vos reponses, je potasse tout cela et je reviens vers vous car comme je le disais au debut, je debute sur le language C et ce n'est pas facile ;-)

Bonjour,

:fleche: EOF tu peux l'utiliser quand tu lis des enregistrements d'une BDD,
:fleche: \n c'est ce qui marque une fin de ligne dans un fichier (saut à la ligne),
:fleche: \0 serait plus adéquat dans ton cas c'est le dernier caractère d'un fichier, d'une chaîne de caractère.

Citation:

---

Envoyé par Martin Lestas

:fleche: \0 serait plus adéquat dans ton cas c'est le dernier caractère d'un fichier, d'une chaîne de caractère.

---

Le dernier caractère d'une chaine de caractère en C, oui (par convention) ; le dernier caractère d'un fichier, non.

Citation:

---

Envoyé par foetus

Parce que le caractère '\n' permet de vider le tampon d'écriture :mrgreen:

---

Cela est plutôt valable pour les tampons en sortie (pour cela que printf("hello, world"); peut ne rien n'afficher (en tout cas, pas forcément tout de suite). Ici, le problème ne vient pas des tampons mais simplement parce que taper au clavier "hello, world" et appuyer sur la touche ENTREE, ça donne "hello, world\n" et non "hello, world"EOF.

Comme dit par Sve@ar, EOF est une valeur spéciale renvoyée par les fonctions de lecture pour signaler que la lecture a échouée car le fin du fichier a été atteinte. Sous Unix, tout est fichier, stdin n'échappe pas à la règle. Mais si stdin est branchée sur le clavier (ce qui est vrai par défaut) et non redirigé sur un "vrai" fichier ou un autre truc (comme montré par leternel et bufferbob), alors tu ne rencontres normalement jamais EOF (sauf à l'envoyer explicitement avec une combinaison de touches).

Citation:

---

Envoyé par Martin Lestas

\0 serait plus adéquat dans ton cas

---

Es-tu sûr que c'est le plus adéquat dans son cas? :mrgreen:
Est-ce que tu peux saisir le caractère '\0' au clavier?

Citation:

---

Envoyé par Bktero

Ici, le problème ne vient pas des tampons mais simplement parce que taper au clavier "hello, world" et appuyer sur la touche ENTREE, ça donne "hello, world\n" et non "hello, world"EOF.

---

Tu as raison :mrgreen:: le printf est derrière la boucle. Donc il devrait avoir une boucle infinie et tuer quitter le programme (CTRL + D).
Mais cela brunounours1 ne nous l'a pas dit


Édit: leternel qui cherche la petite bête :kiss: tuer un programme c'est avec la commande kill pour Linux et au Gestionnaire des tâches sous Windows.

Pour linux, CTRL+D ne tue pas, il clos le flux d'entrée.
Pour windows, je ne crois pas non plus.

Citation:

---

Envoyé par leternel

Pour linux, CTRL+D ne tue pas, il clos le flux d'entrée.

---

Plus précisément, « D » étant la quatrième lettre de l'alphabet, « Ctrl+D » envoie le code 04 (c'est d'ailleurs à cela que sert en fait la touche Ctrl : à émettre les codes de contrôle de la table ASCII lorsque l'on travaille sur un vrai terminal) qui, lui, correspond à EOT (End of Transmission). C'est alors la discipline de ligne du gestionnaire de terminal qui interprète cela comme une commande spéciale et qui considère que toutes les données ont été transmises lorsqu'il travaille en mode ligne (en temps normal) : cela permet d'envoyer la saisie au serveur sans avoir à la terminer par un retour à la ligne.

Un Ctrl-D seul, maintenant, permet d'envoyer officiellement une charge utile de zéro octet, ce qui est officiellement considéré par l'API Unix (read() et recv()) comme une fin de transmission, donc soit comme une fin de fichier, soit comme la fermeture d'une connexion distante (série et/ou téléphonique). Comme les programmes C sont en principe tous faits pour gérer les fins de fichiers de cette façon (ou par fgetc()==EOF), on peut tous les terminer de cette façon depuis le terminal. Essayez avec « cat », par exemple…

Ensuite, l'entrée standard est en principe associée au processus tournant à l'avant-plan, mais si aucun n'est en cours d'exécution, ce processus est alors le shell lui-même et c'est bien à lui que sont envoyées les frappes clavier dans ce cas. Mais ce shell n'échappe pas à la règle et est conçu pour se comporter de la même façon. Envoyer un Ctrl-D seul au shell lui indique alors une fermeture de connexion ou une fin du fichier relié à l'entrée standard et comme il n'y a plus rien à attendre, ce shell décide de prendre fin comme un processus ordinaire.

Le terminal virtuel lui-même n'est alors plus non plus associé à une application et se referme alors automatiquement (sauf configuration spéciale) car a priori, son fichier spécial /dev est alloué à la volée et il n'y aucune raison pour qu'un autre processus le réclame juste après. C'est pour cela que l'on peut refermer un X-Term avec Ctrl-D, et c'est pour cela que les consoles Windows sont faites pour se refermer également par défaut, ce qui cause beaucoup de souci aux étudiants qui débutent avec des applications console et qui n'ont jamais le temps de voir le résultat de leur programme.

Ah.
En fait, il y a une véritable raison à ce que ce soit D et pas autre chose... j'en apprendrais toujours :mrgreen:

Merci!!!

Citation:

---

Envoyé par leternel

En fait, il y a une véritable raison à ce que ce soit D et pas autre chose...

---

Juste histoire de convention (comme les autres CTRL-C, CTRL-Z, CTRL-S, CTRL-Q, ...)

Citation:

---

Envoyé par Sve@r

Juste histoire de convention (comme les autres CTRL-C, CTRL-Z, CTRL-S, CTRL-Q, ...)

---

Oui, mais justement, c'est ce que l'on dit au-dessus. Contrairement aux autres, « Ctrl+D » n'est pas une combinaison de touches choisie au hasard, et d'une manière plus générale, « Ctrl » n'est pas une simple touche « modificatrice », ni a définir des raccourcis clavier comme peut l'être « Alt » sur PC, par exemple : elle existe sur la majorité des terminaux et des ordinateurs de tout type (y compris 8 et 16 bits) et sert réellement à envoyer les codes 1 à 26 car selon l'ASCII, ce sont eux qui permettent de contrôler l'équipement terminal au bout d'une ligne série quand aucune autre infrastructure n'est mise en place dans ce but précis. C'est aussi pour cela que « ESC » porte le code 27 (1Bh) : c'est le premier code après Ctrl+Z (en tant que dernière lettre de l'alphabet).

Ctrl+Q et Ctrl+S sont des combinaisons qui, elles, correspondent exactement aux codes de XON et XOFF, respectivement. Comme elles servent à émuler le contrôle de flux sur les unités de transmission qui sont dépourvues de système pour le faire (à la manière du RTS/CTS des RS/232), c'est tout naturellement qu'elles permettent de mettre automatiquement en mode bloquant n'importe quel processus distant qui utiliserait les commandes standard du C pour écrire vers la sortie (formellement printf), puisque l'opération a lieu au niveau du système. C'est pour cela que depuis un terminal, ça permet de mettre en pause le processus qui écrit sur la sortie standard, mais ce n'est pas, là non plus, une fonctionnalité intrinsèque du terminal virtuel.

Ces codes sont en fait mappés sur les codes DC1 à DC4 de l'ASCII original, qui servent justement à contrôler un périphérique tiers, et notamment à l'allumer ou l'éteindre. Donc forcément une combinaison parmi Ctrl+Q, Ctrl+R, Ctrl+S et Ctrl+T. Maintenant, pourquoi celles-ci en particulier ? Selon Wikipédia, c'était un choix du populaire Télétype Model 33 sorti en 1963, soit la même année que la toute première version officielle de l'ASCII. Il n'y a pas d'explication officielle mais apparemment, DC1 et DC3 correspondaient déjà plus ou moins à « Enable » et « Disable ». Et « Ctrl+S » pourrait bien signifier « Stop » dans l'inconscient collectif même s'il semblerait qu'ASCII associait alors ce mot à DC4.

Ctrl+Z, lui, semble avoir vraiment été choisi arbitrairement, au moment où l'on a commencé à utiliser la touche Ctrl comme raccourci clavier. Le code 26 correspond à SUB, qui n'avait de sens que lors d'une transmission de données en mode texte le long d'une ligne potentiellement à erreurs. Il est assez courant de reléguer en fin de table des codes qui n'ont pas encore de place officielle et il est intéressant de remarquer qu'initialement, les codes ESC et ACK se trouvaient eux-mêmes tout-à-fait à la fin de la table ASCII avant d'être renvoyés en 1967 vers leur place légitime : la colonne des codes de contrôle.

On trouve ici une copie peu courante du document original de 1963, repris ensuite en 1965 puis 1967 : http://worldpowersystems.com/projects/codes/X3.4-1963/
Et surtout sur la page 5 : http://worldpowersystems.com/project...1963/page5.JPG
ainsi qu'un décryptage des différents codes de contrôle ici : http://worldpowersystems.com/J/codes/#DC1