Discussion :

[baccali]

Bonjour,

Suite à un problème que j'ai rencontré quelques jours auparavent et donv j'ai parlé sur le forum http://www.developpez.net/forums/d11...pe-eof-non-lu/ j'en suis arrivé à "débattre" sur le fait de pouvoir écrire un EOF (End Of File) sur un flux sans que le flux ne fermé. Je pensais que cela devait être possible d'après le peu de chose que j'ai lu dessus.
- puts qui le convertit en caractère avant de l'utiliser.
- Macro implémentée dans la libc.

Mais l'on m'a répondu que ce n'était qu'une macro pour tester le retour des fonctions comme fread() (ce que je trouve un peu bizarre (voi topic)). Je n'ai Pas remis sa Parole en doute mais voila qu'en me documentant sur l'unicode je tombe sur une nouvelle macro, WEOF. Donc je suis maintenant presque sur qu'il doit être possible de spécifier un EOF dans un flux sans pour autant fermer ce flux.

Donc je voulais avoir la confirmation par un autre expert que cela est vraiment impossible et si c'est possible. Comment faire, quelle fonctiln doit on appeler (vu que DE CE QUE J'AI COMPRIS puts() etc... Effectuent une conversion en caractère ansi ou unicode avant d'écrire). Car les bouts de code que je cite dans le sujet précédent ne marchent tout simolement pas! Cela vient-il de ctags?

Merci

[6-MarViN]

Pourquoi vouloir absolument écrire un EOF? Déja oui écrire un EOF dans un flux (que ce soit possible ou non) ferme le flux (que ce soit un pipe, une socket...). En réseau, quand on envoie un paquet via une socket, en général à la fin de cet envoie on met un \n pour signaler que c'est bien la fin du paquet. Pourquoi ne pas faire la même chose avec ton pipe?

Et pour revenir au sujet d'est-il possible d'écrire un EOF sans fermer un flux, la réponse est probablement pas. Sur un système Unix, TOUT est fichier, ce qui veut dire que même les flux (peux importe lesquels) sont des fichiers. Or un EOF représente la fin d'un fichier. Donc si tu écrit un EOF dans un flux, tu lui signal qu'il est arrivé à la fin et donc il s'arrete.

[baccali]

Bonjour,

As tu lu la discussion que j'ai cité? L'utilité y est donné. Si je suis sensé lancer des milliers un processus qui attend un EOF sur un flux dans lequel tu écris pour se fermer, c'est plus rapide et simple d'écrire directement EOF dans le flux plutôt que de devoir fermer le fd à chaque fois.

Ce sera plus clair si tu lisais la discussion que je n'ai pas poster pour rien! (les derniers messages sont le sujet même de ce topic!)

Merci

[6-MarViN]

Pas besoin d'être agressif bonhomme. Sinon même si tu peux écrire un EOF dans un flux, ça le fermera.

[jeroman]

EOF est justement une valeur spéciale ne correspondant pas à un caractère.

Je vais te donner un exemple. Quand on lit le man de fgetc, on trouve ceci :

fgetc() lit le caractère suivant depuis le flux stream et le renvoie sous forme d'un unsigned char, transformé en int, ou EOF en cas d'erreur ou de fin de fichier.

Cette fonction est là pour renvoyer le caractère du flux en question (1 octet), mais elle est conçue également pour indiquer si le fichier est terminé ou si une erreur est survenue.
Un caractère fait 1 octet. La valeur retournée est comprise entre 0 et 255, ce qui correspond à la plage d'un unsigned char. Comment alors la fonction doit-elle s'y prendre pour renvoyer une valeur spéciale correspondant à une erreur, mais qui ne doit surtout pas être confondue avec la valeur d'un caractère lu sur le flux ? Il lui suffit tout simplement de renvoyer une valeur de, non pas 1 octet, mais de >=2 octets. Et EOF est justement une valeur entière qui n'est pas comprise entre 0 et 255. Elle vaut souvent (toujours ?) -1, afin qu'elle ne soit justement pas confondue avec la valeur d'un caractère, dont la valeur est comprise entre 0 et 255.

Donc, c'est la raison pour laquelle la doc de fgetc indique que le caractère lu sur le flux est d'abord un unsigned char (valeur entre 0 et 255), mais qu'il est ensuite converti en int (dont la taille est de 2 ou 4 octets), afin que la fonction permette justement d'envoyer soit la valeur du caractère lu (unsigned char casté en int, ce qui ne change pas sa valeur), soit la valeur spéciale EOF (-1 codé en int) en cas d'erreur ou de fin de fichier. Si EOF était codé sur un seul octet, il serait immanquablement confondu avec le caractère 255 (car -1, valeur de EOF, correspond à 255 en valeur non signée 8 bits) ; cela poserait un gros problème.

Et si je voulais utiliser fputc pour "envoyer" EOF sur un flux, ce EOF serait considéré par la fonction comme un caractère normal. En fait, il serait casté en unsigned char, ce qui enverrait le caractère 255 sur le flux et non EOF.

J'ai pris comme exemple fgetc / fputc pour t'expliquer le principe. Mais ça marche comme ça partout. Je ne suis pas calé en matière de païpe (), mais comme il s'agit de fichiers, cela doit fonctionner de la même manière.

[baccali]

Ok alors autant pour moi, Tout est devenu beaucoup plus clair avec ton explication sur les casts jeroman.

Donc si j'ai bien compris, la macro EOF sert à désigner la valeur retour envoyé par fgetc une fois casté en int. Jusque là ok çà explique d'ailleurs pourquoi fread() renvoie un size_t et non un char * (qui paraissait plus logique) et pourquoi une macro pour l'unicode. Je dormirai déjà moins bête (je débute encore en C sous Linux, et en C tout court d'ailleurs). Mais j'aurai encore une petite question à te poser :


Ce que je n'arrive vraiment pas à comprendre c'est pourquoi cette valeur spécialement (-1). Dès le moment où cette valeur est castée en int pourquoi ne pas avoir dit qu'un (int) -1 correspondrait à un EOF alors que toute autre valeur qui ne correspondrait pas à un char casté en int correspondrait à une erreur (je ne sais pas si je suis assez clair mais bon... Tout se joue sur les 3 octet de tête). Cela n'aurait-il pas simplifier les choses, on n'aurait pas besoin de vérifier effectivement la fin du fichier ou une erreur avec un feof() et un ferror().


Merci merci merci pour tes réponses.