valeur de retour EOF

Bonjour,

Dans le livre de K&R Norme ANSI il y a un programme très simple qui est le suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

main () { int c;   c = getchar (); while (c != EOF) { putchar (c); c = getchar (); } }

---

Seulement sur ma machine la valeur de EOF est -1 et par conséquent, comme getchar lit caractère par caractère quand je rentre -1, il me lit dabord '-' puis '1' et donc la condition c !=EOF est toujours vraie.

Le programme ne termine donc pas!

De plus dans le livre il est écrit :

Citation:

---

Le problème est de détecter la fin de données en entrée. La solution est que getchar retourne une valeur particulière lorsqu'il n'y a plus rien en entrée, une valeur que l'on ne puisse pas confondre avec un vrai caractère. Cette valeur s'appelle EOF ...

---

On dirait qu'ils considèrent que l'entrée standart c'est un fichier!
Or mon entrée standart c'est mon terminal. Donc a quelle moment le programme sait qu'il n'y a plus rien en entrée puisque je peux tjrs écrire dans la console?

j'espère que vous m'avez compris! Merci d'avance

Ça dépend de ton OS. CTRL-Z et CTRL-D sont les deux possibilités les plus courantes.

Bonjour,

normalement, la constante EOF est prévu pour la fin d'un fichier !!! et non de la console.
Il te reste donc trois possibilité :
- tout mettre dans un fichier : ça ira plus vite, tu ne devra pas tout retapper à la main !!! C'est ce que tout le monde fait.
- mettre un autre caractère pour signaler la fin de la saisie : #, @, $, €, ...
- lire les caractères par couple.

Citation:

---

Envoyé par ToTo13

normalement, la constante EOF est prévu pour la fin d'un fichier !!! et non de la console.

---

Bétises...

stdin est in flux. EOF (Acronyme mal choisi, EOR aurait évité bien des confusions...) signifie "fin de lecture". Si stdin est raccordé à une console, la façon de signaler une fin de lecture dépend du système :

Unixoide : Ctrl-D (par défaut)
MS-DOS/Windows : Ctrl-Z

etc.

Merci pour vôtre réponse (Emmanuel Delahaye ):D ,
car mon ancienne prof de C avancée nous avait appris que EOF était la fin d'un fichier (pas d'un flux) :( .
C'est là que l'on voit qu'il est difficile de tout connaître même dans sa partie. ;)

Sisi EOF = end of file, c'est juste que stdin et stdout sont aussi des "file"

Citation:

---

Envoyé par Gruik

Sisi EOF = end of file, c'est juste que stdin et stdout sont aussi des "file"

---

Oui, mais comme je l'ai fait remarqué, l'acronyme EOF est mal choisi, car c'est un évènement qui signifie 'fin de lecture".

Si on tient à en connaitre la cause (rarement utile), on utilise feof() et ferror().

http://emmanuel-delahaye.developpez....s.htm#fichiers

D'autre part, stdin et stdin ne sont pas des "file", mais des flux ou streams. La terminologie des flux est assez floue et confusante en C. Elle a été améliorée en C++ ou tout est clairement basé sur le mot stream.

Citation:

---

EOF est mal choisi, car c'est un évènement qui signifie 'fin de lecture"

---

Je suis d'accord que c'est mal choisi, mais pas que ça signifie "fin de lecture". Une petite recherche de EOF dans C99 donne:

- fclose() retourne EOF en cas d'erreur
- fflush() retourne EOF en cas d'erreur
- ?scanf() retourne EOF s'il y a une erreur avant la première conversion
- fgetc() retourne EOF en cas d'erreur ou de fin de fichier
- fputc() retourne EOF en cas d'erreur
- ungetc() retourne EOF en cas d'erreur
- wctob() retourne EOF en cas d'erreur

J'en ai passé et j'arrête ici. EOF est utilisé pour signaler que la fonction n'a pas pu remplir son rôle.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Je suis d'accord que c'est mal choisi, mais pas que ça signifie "fin de lecture".

---

C'est une incoherence dans la norme alors, car la section 7.19.1 definit bien:

Citation:

---

EOF
which expands to an integer constant expression, with type int and a negative value, that
is returned by several functions to indicate end-of-file, that is, no more input from a
stream;

---

Ils ont du se dire qu'ajouter une autre macro d'erreur etait inutile...

Citation:

---

Envoyé par DaZumba

C'est une incoherence dans la norme alors, car la section 7.19.1 definit bien:

Ils ont du se dire qu'ajouter une autre macro d'erreur etait inutile...

---

"no more input from a stream;" a bien la sémantique de "fin de lecture" que je revendique (littéralement "plus d'entrée en provenance d'un flux").

Citation:

---

Envoyé par Emmanuel Delahaye

"no more input from a stream;" a bien la sémantique de "fin de lecture" que je revendique (littéralement "plus d'entrée en provenance d'un flux").

---

Oui, spot on. Mais la remarque de Jean-Marc est tres pertinente: on ne peut pas dire, par exemple, que le retour EOF de ?scanf() en cas de non-conversion signifie "no more input". C'est plutot "bad input"... Une certaine ambivalence regne donc autour de EOF, qui aurait tres bien pu s'appeler IOERR !

Citation:

---

Envoyé par DaZumba

Oui, spot on. Mais la remarque de Jean-Marc est tres pertinente: on ne peut pas dire, par exemple, que le retour EOF de ?scanf() en cas de non-conversion signifie "no more input". C'est plutot "bad input"... Une certaine ambivalence regne donc autour de EOF, qui aurait tres bien pu s'appeler IOERR !

---

Pour la non-convesion, je ne suis pas d'accord. fscanf() retourne le nombre de conversions réussies (0,1,2...). Il retourne EOF (<0) en cas d'erreur de lecture ou de fin de fichier, comme fgetc() (dont il vient directement, très probablement).

Je soutiens que le nom correct devrait être EOR (End Of Reading).

Citation:

---

Envoyé par n1124

7.19.6.2 The fscanf function
<...>
Returns
16 The fscanf function returns the value of the macro EOF if an input failure occurs
before any conversion. Otherwise, the function returns the number of input items
assigned, which can be fewer than provided for, or even zero, in the event of an early
matching failure.

---

Bien que je sois loin du niveau de la discution, je suis assez d'accord pour EOR, cela semble logique ;)

Cependant, ils ne sont pas mauvais ceux qui l'ont écrit ce système non ? 8O

Ils ont du y penser (peut-être pas à tous certes :P ), il y a eu certaines bonnes (ou mauvaises) raisons peut-être à cela ?

Car une macro de plus ne les auraient pas tuer ? :mouarf:

Non ? :aie: (pas sur la tête ! :P )

Citation:

---

Envoyé par O( N )

Cependant, ils ne sont pas mauvais ceux qui l'ont écrit ce système non ? 8O

---

système ? Quel système ? Le langage C n'est pas un 'système'...

Par contre, il existe depuis plus de 30 ans. Il est normalisé depuis 1989, trop tard pour changer ce genre de chose.

Contrairement à BASIC ou Pascal, C n'est pas un langage universitaire mais industriel. Il n'a donc pas été aussi bien pensé et de nombreux défauts et faiblesses subsistent. Mais il reste inégalé au niveau compacité, simplicité apparente, élégance, efficacité, abstraction, portabilité, accès système, accès machine,

C'est ce qui fait que la programmation C est à la fois une science et un art.

Ils avaient la flemme de créer d'autres constantes...
Enfin, c'est comme pour errno, il ya un nombre limité d'erreurs possibles, et pour chaque fonction, les erreurs possibles ont une signification particulière, une signification specifique à la fonction.
C'est pareil pour EOF... garder la meme constante mais changer son sens suivant le contexte, pourquoi pas.

oups :mouarf: je n'entendais pas OS par le mot 'système'.

C'est donc pour la raison industrielle qu'ils n'ont pas développé plus loin :P

Et le mélange : normes, libs et versions ( si tent est qu'il en existe plusieurs ) n'ont pas su résoudre ce genre de problème.

(Me trompais-je peut-être mais JAVA est industriel et pourtant il est remanié de temps en temps et acquière de nouvelles versions en changeant ses fonctions (entre autres) ?)

Pourquoi pas 'C' (si cela est bien le cas de Java) ? :)

Citation:

---

Envoyé par Emmanuel Delahaye

Contrairement à BASIC ou Pascal, C n'est pas un langage universitaire mais industriel. Il n'a donc pas été aussi bien pensé et de nombreux défauts et faiblesses subsistent.

---

Et bien pour pascal, je n'ai pas trop d'idée sur la question, mais d'après certains de mes anciens profs pour ne pas dire tous !
Pour eux BASIC est à mettre aux oubliettes et reste mauvais pour faire de la vraie programmation.

Personnellement je viens d'un AMSTRAD CPC 6128 :D avec un BASIC puis le basic de WINDOWS par la suite, avant de devenir pour un temps Pascalien puis Cphage, Javaphobe et Schemephile :aie:

Le problème principale dans le basic est la commande GOTO qui permet la création de programme spaguettis.
(calculer la complexité à partir d'un tel programme est une bonne blague, il me semble :P )

Il est vrai qu'un programme lisible plait, en plus si il est clair il devient interressant. Si de plus il est optimisé, on reste un momment dessus pour bien sans rappeler ( je suis d'accord pour l'art ;) ) (Bien que je sois encore au niveau de confondre moderne et impressionnisme au niveau du code :aie: , cela viendra avec le temps :mouarf: )

Wouahouuuu....8O 8O J'étais loin d'imaginer que ce post allait faire polèmique !!

En tout cas merci à tous pour toutes vos réponses :D

Après plusieurs relecture de vos réponses, j'ai fait de même avec le paragraphe du livre de K&R que je n'avais pas compris!
Voici un passage qui m'a alors interpellé :

Citation:

---

Les entrées et sorties de texte, quelles que soient leur provenance et leur destination, sont manipulées en tant que flots de caractères. Un flot de texte (text stream) est une séquence de caractères divisée en lignes; chaque ligne est constituée d'une suite de séquence de caractères éventuellement vide, suivie d'un caractère de fin de ligne

---

C'est pourquoi le programme qui copie son entrée sur sa sortie caractère par caractère attend le caractère de fin de ligne (l'appuie sur la touche entrée) pour recopier le texte en entrée! C'est loin d'être évident si l'on a jamais pris connaissance du modèle d'entrées-sorties de la bibliothèque standart! Au début je m'attendais à ce que le programme imprime le caractère que je venais d'entrer, à la suite. Comme ceci :
--> ssaalluutt

De plus en lisant ce passage, je comprend que le C ne se préoccupe jamais de savoir qu'elle est son entrée standart et sa sortie standart.
Peu importe que l'entrée ou la sortie standart soit un fichier ou l'écran, les E/S seront traitées de la même façon :
-suite de caractères suivie d'un carctère de fin ligne
-renvoi EOF=End of File lorsqu'il n'y a plus rien à lire sauf si l'entrée standart c'est l'ecran, dans quel cas, il faut préciser soi-même qu'il n'y a plus rien à lire et donc taper CTRL-d (qui est la valeur de EOF dans le système UNIX).
C'est la raison pour laquelle Emmanuel Delahaye défend que la valeur EOF a plus la signification d'un EOR (end of read)

Ai-je bien tout compris ou suis-je encore plus mal loti qu'au départ ??? :aie:

Citation:

---

Envoyé par DiabolO

Ai-je bien tout compris ou suis-je encore plus mal loti qu'au départ ??? :aie:

---

Ca me va.

Citation:

---

Ca me va.

---

Coooooool.... Un petit "Résolu" alors !! :mrgreen: