je reviens sur un problème qui me traine en tête depuis
longtemps.
Le coeur du pb, c'est "comment détecter la fin de fichier
si sizeof(int)==1" ?
Commençons par dire qu'il ne peut pas y avoir de "trap value"
dans un unsigned char, ie il peut représenter toutes
les valeurs dans 0..2^(CHAR_BITS-1).
Mais bon, avec sizeof(int)==1, on va avoir des entiers qui
représentent au plus 2^CHAR_BITS valeurs.
Or, fgetc, getc, getchar retourne un int qui est soit un
unsigned char convertit en int, soit EOF.
Mais bon, sur une telle implentation, si j'écrit EOF
dans un fichier, comment je fais pour le retrouver ?
int i=EOF;
unsigned char* p=&i; // J'ai le droit
FILE* f= fopen("toto.txt", "w");
assert(f);
fwrite( p, sizeof(i) , 1, f);
fclose(f);
f= fopen("toto.txt", "r");
int c= fgetc(f);
// Et là, c, il vaut quoi ?
Bon, ok, si j'ai pas la réponse, ça devrait pas changer
trop mon quotidien, mais bon, à chaque fois que j'enseigne
le coup du "EOF hors de l'espace de représentation de char",
je pense à nos cartes DSP où char et int font 32 bits...
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Le coeur du pb, c'est "comment détecter la fin de fichier si sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de l'espace de représentation de char", je pense à nos cartes DSP où char et int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis, la conclusion avait ete qu'il n'etait pas possible d'avoir une implementation "hosted" ayant cette caracteristique parce que la bibliotheque standard n'etait pas implementable de maniere conforme.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Le coeur du pb, c'est "comment détecter la fin de fichier si
sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon
quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de
l'espace de représentation de char", je pense à nos cartes DSP où char et
int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis,
la conclusion avait ete qu'il n'etait pas possible d'avoir une
implementation "hosted" ayant cette caracteristique parce que la
bibliotheque standard n'etait pas implementable de maniere conforme.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Le coeur du pb, c'est "comment détecter la fin de fichier si sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de l'espace de représentation de char", je pense à nos cartes DSP où char et int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis, la conclusion avait ete qu'il n'etait pas possible d'avoir une implementation "hosted" ayant cette caracteristique parce que la bibliotheque standard n'etait pas implementable de maniere conforme.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
On 2008-02-28, Jean-Marc Bourguet wrote:
Marc Boyer writes:
Le coeur du pb, c'est "comment détecter la fin de fichier si sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de l'espace de représentation de char", je pense à nos cartes DSP où char et int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis, la conclusion avait ete qu'il n'etait pas possible d'avoir une implementation "hosted" ayant cette caracteristique parce que la bibliotheque standard n'etait pas implementable de maniere conforme.
Ma mémoire sélective avait du repousser cette éventualité...
Merci, Marc -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
On 2008-02-28, Jean-Marc Bourguet <jm@bourguet.org> wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Le coeur du pb, c'est "comment détecter la fin de fichier si
sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon
quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de
l'espace de représentation de char", je pense à nos cartes DSP où char et
int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis,
la conclusion avait ete qu'il n'etait pas possible d'avoir une
implementation "hosted" ayant cette caracteristique parce que la
bibliotheque standard n'etait pas implementable de maniere conforme.
Ma mémoire sélective avait du repousser cette éventualité...
Merci,
Marc
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Le coeur du pb, c'est "comment détecter la fin de fichier si sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de l'espace de représentation de char", je pense à nos cartes DSP où char et int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis, la conclusion avait ete qu'il n'etait pas possible d'avoir une implementation "hosted" ayant cette caracteristique parce que la bibliotheque standard n'etait pas implementable de maniere conforme.
Ma mémoire sélective avait du repousser cette éventualité...
Merci, Marc -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Jean-Marc Bourguet
Marc Boyer writes:
On 2008-02-28, Jean-Marc Bourguet wrote:
Marc Boyer writes:
Le coeur du pb, c'est "comment détecter la fin de fichier si sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de l'espace de représentation de char", je pense à nos cartes DSP où char et int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis, la conclusion avait ete qu'il n'etait pas possible d'avoir une implementation "hosted" ayant cette caracteristique parce que la bibliotheque standard n'etait pas implementable de maniere conforme.
Ma mémoire sélective avait du repousser cette éventualité...
Ouf. Je craignais que tu me dises que tes DSP avaient une lib standard :-)
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
On 2008-02-28, Jean-Marc Bourguet <jm@bourguet.org> wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Le coeur du pb, c'est "comment détecter la fin de fichier si
sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon
quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de
l'espace de représentation de char", je pense à nos cartes DSP où char et
int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis,
la conclusion avait ete qu'il n'etait pas possible d'avoir une
implementation "hosted" ayant cette caracteristique parce que la
bibliotheque standard n'etait pas implementable de maniere conforme.
Ma mémoire sélective avait du repousser cette éventualité...
Ouf. Je craignais que tu me dises que tes DSP avaient une lib standard :-)
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Le coeur du pb, c'est "comment détecter la fin de fichier si sizeof(int)==1" ?
[...]
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de l'espace de représentation de char", je pense à nos cartes DSP où char et int font 32 bits...
Si j'ai bonne memoire, la derniere fois que le sujet est venu sur le tapis, la conclusion avait ete qu'il n'etait pas possible d'avoir une implementation "hosted" ayant cette caracteristique parce que la bibliotheque standard n'etait pas implementable de maniere conforme.
Ma mémoire sélective avait du repousser cette éventualité...
Ouf. Je craignais que tu me dises que tes DSP avaient une lib standard :-)
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Charlie Gordon
"Marc Boyer" a écrit dans le message de news:
Bonjour à tous,
je reviens sur un problème qui me traine en tête depuis longtemps.
Le coeur du pb, c'est "comment détecter la fin de fichier si sizeof(int)==1" ?
Commençons par dire qu'il ne peut pas y avoir de "trap value" dans un unsigned char, ie il peut représenter toutes les valeurs dans 0..2^(CHAR_BITS-1).
Mais bon, avec sizeof(int)==1, on va avoir des entiers qui représentent au plus 2^CHAR_BITS valeurs.
Or, fgetc, getc, getchar retourne un int qui est soit un unsigned char convertit en int, soit EOF.
Mais bon, sur une telle implentation, si j'écrit EOF dans un fichier, comment je fais pour le retrouver ?
int i=EOF; unsigned char* p=&i; // J'ai le droit FILE* f= fopen("toto.txt", "w"); assert(f); fwrite( p, sizeof(i) , 1, f); fclose(f); f= fopen("toto.txt", "r"); int c= fgetc(f); // Et là, c, il vaut quoi ?
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de l'espace de représentation de char", je pense à nos cartes DSP où char et int font 32 bits...
Bon, sans prendre parti trop ouvertement contre ces architectures frustes ou l'implementation de stdio est sans grand intérêt, il me semble simple de tester la fin de fichier de la facon suivante:
int c = fgetc(f); if (c == EOF && feof(f)) { /* Youpi! c'est la fin de ficher! */ }
et plus simplement d'ailleurs, mais potentiellement moins efficacement:
if (feof(f)) { /* Ben oui, c'est le bon test pour la fin de fichier */ }
Pour etre vraiment exhaustif, il faudrait aussi tester ferror(f)
-- Chqrlie.
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrnfsdha5.cqf.Marc.Boyer@ubu.enseeiht.fr...
Bonjour à tous,
je reviens sur un problème qui me traine en tête depuis
longtemps.
Le coeur du pb, c'est "comment détecter la fin de fichier
si sizeof(int)==1" ?
Commençons par dire qu'il ne peut pas y avoir de "trap value"
dans un unsigned char, ie il peut représenter toutes
les valeurs dans 0..2^(CHAR_BITS-1).
Mais bon, avec sizeof(int)==1, on va avoir des entiers qui
représentent au plus 2^CHAR_BITS valeurs.
Or, fgetc, getc, getchar retourne un int qui est soit un
unsigned char convertit en int, soit EOF.
Mais bon, sur une telle implentation, si j'écrit EOF
dans un fichier, comment je fais pour le retrouver ?
int i=EOF;
unsigned char* p=&i; // J'ai le droit
FILE* f= fopen("toto.txt", "w");
assert(f);
fwrite( p, sizeof(i) , 1, f);
fclose(f);
f= fopen("toto.txt", "r");
int c= fgetc(f);
// Et là, c, il vaut quoi ?
Bon, ok, si j'ai pas la réponse, ça devrait pas changer
trop mon quotidien, mais bon, à chaque fois que j'enseigne
le coup du "EOF hors de l'espace de représentation de char",
je pense à nos cartes DSP où char et int font 32 bits...
Bon, sans prendre parti trop ouvertement contre ces architectures frustes ou
l'implementation de stdio est sans grand intérêt, il me semble simple de
tester la fin de fichier de la facon suivante:
int c = fgetc(f);
if (c == EOF && feof(f)) {
/* Youpi! c'est la fin de ficher! */
}
et plus simplement d'ailleurs, mais potentiellement moins efficacement:
if (feof(f)) {
/* Ben oui, c'est le bon test pour la fin de fichier */
}
Pour etre vraiment exhaustif, il faudrait aussi tester ferror(f)
je reviens sur un problème qui me traine en tête depuis longtemps.
Le coeur du pb, c'est "comment détecter la fin de fichier si sizeof(int)==1" ?
Commençons par dire qu'il ne peut pas y avoir de "trap value" dans un unsigned char, ie il peut représenter toutes les valeurs dans 0..2^(CHAR_BITS-1).
Mais bon, avec sizeof(int)==1, on va avoir des entiers qui représentent au plus 2^CHAR_BITS valeurs.
Or, fgetc, getc, getchar retourne un int qui est soit un unsigned char convertit en int, soit EOF.
Mais bon, sur une telle implentation, si j'écrit EOF dans un fichier, comment je fais pour le retrouver ?
int i=EOF; unsigned char* p=&i; // J'ai le droit FILE* f= fopen("toto.txt", "w"); assert(f); fwrite( p, sizeof(i) , 1, f); fclose(f); f= fopen("toto.txt", "r"); int c= fgetc(f); // Et là, c, il vaut quoi ?
Bon, ok, si j'ai pas la réponse, ça devrait pas changer trop mon quotidien, mais bon, à chaque fois que j'enseigne le coup du "EOF hors de l'espace de représentation de char", je pense à nos cartes DSP où char et int font 32 bits...
Bon, sans prendre parti trop ouvertement contre ces architectures frustes ou l'implementation de stdio est sans grand intérêt, il me semble simple de tester la fin de fichier de la facon suivante:
int c = fgetc(f); if (c == EOF && feof(f)) { /* Youpi! c'est la fin de ficher! */ }
et plus simplement d'ailleurs, mais potentiellement moins efficacement:
if (feof(f)) { /* Ben oui, c'est le bon test pour la fin de fichier */ }
Pour etre vraiment exhaustif, il faudrait aussi tester ferror(f)
-- Chqrlie.
Jean-Marc Bourguet
"Charlie Gordon" writes:
if (feof(f)) { /* Ben oui, c'est le bon test pour la fin de fichier */ }
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a echoue. Et comment savoir si fgetc() a echoue si cette fonction peut retourner EOF sans echouer (errno n'est pas non plus une solution pour la meme raison) ? Si la derniere entree n'a pas echoue, le fait que feof(f)!=0 indique simplement que la prochaine echouera.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Charlie Gordon" <news@chqrlie.org> writes:
if (feof(f)) {
/* Ben oui, c'est le bon test pour la fin de fichier */
}
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a
echoue. Et comment savoir si fgetc() a echoue si cette fonction peut
retourner EOF sans echouer (errno n'est pas non plus une solution pour la
meme raison) ? Si la derniere entree n'a pas echoue, le fait que
feof(f)!=0 indique simplement que la prochaine echouera.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
if (feof(f)) { /* Ben oui, c'est le bon test pour la fin de fichier */ }
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a echoue. Et comment savoir si fgetc() a echoue si cette fonction peut retourner EOF sans echouer (errno n'est pas non plus une solution pour la meme raison) ? Si la derniere entree n'a pas echoue, le fait que feof(f)!=0 indique simplement que la prochaine echouera.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre
Dans l'article , Jean-Marc Bourguet écrit:
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a echoue. Et comment savoir si fgetc() a echoue si cette fonction peut retourner EOF sans echouer (errno n'est pas non plus une solution pour la meme raison) ? Si la derniere entree n'a pas echoue, le fait que feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que lorsque la fin de fichier a été détectée suite à une lecture. Mais il me semble que la norme n'est pas très claire sur ce point.
Dans l'article <pxbod9rolqe.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a
echoue. Et comment savoir si fgetc() a echoue si cette fonction peut
retourner EOF sans echouer (errno n'est pas non plus une solution pour la
meme raison) ? Si la derniere entree n'a pas echoue, le fait que
feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que
lorsque la fin de fichier a été détectée suite à une lecture. Mais
il me semble que la norme n'est pas très claire sur ce point.
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a echoue. Et comment savoir si fgetc() a echoue si cette fonction peut retourner EOF sans echouer (errno n'est pas non plus une solution pour la meme raison) ? Si la derniere entree n'a pas echoue, le fait que feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que lorsque la fin de fichier a été détectée suite à une lecture. Mais il me semble que la norme n'est pas très claire sur ce point.
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a echoue. Et comment savoir si fgetc() a echoue si cette fonction peut retourner EOF sans echouer (errno n'est pas non plus une solution pour la meme raison) ? Si la derniere entree n'a pas echoue, le fait que feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que lorsque la fin de fichier a été détectée suite à une lecture, i.e. on a feof(f) != 0 forcément suite à un échec. Mais il me semble que la norme n'est pas très claire sur ce point.
Dans l'article <pxbod9rolqe.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a
echoue. Et comment savoir si fgetc() a echoue si cette fonction peut
retourner EOF sans echouer (errno n'est pas non plus une solution pour la
meme raison) ? Si la derniere entree n'a pas echoue, le fait que
feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que
lorsque la fin de fichier a été détectée suite à une lecture, i.e.
on a feof(f) != 0 forcément suite à un échec. Mais il me semble que
la norme n'est pas très claire sur ce point.
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a echoue. Et comment savoir si fgetc() a echoue si cette fonction peut retourner EOF sans echouer (errno n'est pas non plus une solution pour la meme raison) ? Si la derniere entree n'a pas echoue, le fait que feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que lorsque la fin de fichier a été détectée suite à une lecture, i.e. on a feof(f) != 0 forcément suite à un échec. Mais il me semble que la norme n'est pas très claire sur ce point.
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a echoue. Et comment savoir si fgetc() a echoue si cette fonction peut retourner EOF sans echouer (errno n'est pas non plus une solution pour la meme raison) ? Si la derniere entree n'a pas echoue, le fait que feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que lorsque la fin de fichier a été détectée suite à une lecture, i.e. on a feof(f) != 0 forcément suite à un échec. Mais il me semble que la norme n'est pas très claire sur ce point.
Je ne pense pas que fgetc puisse amener dans ce cas la dans les implementations courantes (mais il semble me souvenir que la norme de l'interdit pas formellement). On peut y arriver relativement facilement avec fgets et scanf en forcant une fin de fichier sans fin de ligne (deux CTRL-D consecutif dans le terminal sous Unix par exemple, je viens de tester mais j'ai un resultat qui m'etonne, bien que feof(stdin) soit different de 0, l'entree suivante n'echoue pas d'office mais attend encore un CTRL-D -- rapide verification, la norme ne parle de tester le "end-of-file indicator" que pour fgetc, pas pour fgets et fgets n'est pas decrit en fonction de fgetc... en C++ la situation est plus claire)
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre <vincent+news@vinc17.org> writes:
Dans l'article <pxbod9rolqe.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a
echoue. Et comment savoir si fgetc() a echoue si cette fonction peut
retourner EOF sans echouer (errno n'est pas non plus une solution pour la
meme raison) ? Si la derniere entree n'a pas echoue, le fait que
feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que
lorsque la fin de fichier a été détectée suite à une lecture, i.e.
on a feof(f) != 0 forcément suite à un échec. Mais il me semble que
la norme n'est pas très claire sur ce point.
Je ne pense pas que fgetc puisse amener dans ce cas la dans les
implementations courantes (mais il semble me souvenir que la norme de
l'interdit pas formellement). On peut y arriver relativement facilement
avec fgets et scanf en forcant une fin de fichier sans fin de ligne (deux
CTRL-D consecutif dans le terminal sous Unix par exemple, je viens de
tester mais j'ai un resultat qui m'etonne, bien que feof(stdin) soit
different de 0, l'entree suivante n'echoue pas d'office mais attend encore
un CTRL-D -- rapide verification, la norme ne parle de tester le
"end-of-file indicator" que pour fgetc, pas pour fgets et fgets n'est pas
decrit en fonction de fgetc... en C++ la situation est plus claire)
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Oui, mais c'est un test qu'on ne peut faire qu'apres qu'une entree a echoue. Et comment savoir si fgetc() a echoue si cette fonction peut retourner EOF sans echouer (errno n'est pas non plus une solution pour la meme raison) ? Si la derniere entree n'a pas echoue, le fait que feof(f)!=0 indique simplement que la prochaine echouera.
Euh, je ne pense pas. L'indicateur end-of-file n'est positionné que lorsque la fin de fichier a été détectée suite à une lecture, i.e. on a feof(f) != 0 forcément suite à un échec. Mais il me semble que la norme n'est pas très claire sur ce point.
Je ne pense pas que fgetc puisse amener dans ce cas la dans les implementations courantes (mais il semble me souvenir que la norme de l'interdit pas formellement). On peut y arriver relativement facilement avec fgets et scanf en forcant une fin de fichier sans fin de ligne (deux CTRL-D consecutif dans le terminal sous Unix par exemple, je viens de tester mais j'ai un resultat qui m'etonne, bien que feof(stdin) soit different de 0, l'entree suivante n'echoue pas d'office mais attend encore un CTRL-D -- rapide verification, la norme ne parle de tester le "end-of-file indicator" que pour fgetc, pas pour fgets et fgets n'est pas decrit en fonction de fgetc... en C++ la situation est plus claire)
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Jean-Marc Bourguet writes:
je viens de tester mais j'ai un resultat qui m'etonne,
Apres analyse, j'ai decide de poser la question sur comp.std.c.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet <jm@bourguet.org> writes:
je viens de tester mais j'ai un resultat qui m'etonne,
Apres analyse, j'ai decide de poser la question sur comp.std.c.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
je viens de tester mais j'ai un resultat qui m'etonne,
Apres analyse, j'ai decide de poser la question sur comp.std.c.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Jean-Marc Bourguet writes:
Jean-Marc Bourguet writes:
je viens de tester mais j'ai un resultat qui m'etonne,
Apres analyse, j'ai decide de poser la question sur comp.std.c.
Pour info pour ceux qui ne sont pas alle voir, c'est bien un bug. 7.19.3/11 impose que toute lecture soit faite comme si on utilisait fgetc et fgetc echoue si le marqueur de fin de fichier est mis.
Note historique: le comportement traditionnel etait bien celui que j'ai observe sur Linux et Solaris mais la norme a toujours demande le comportement que je trouve plus coherent.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet <jm@bourguet.org> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
je viens de tester mais j'ai un resultat qui m'etonne,
Apres analyse, j'ai decide de poser la question sur comp.std.c.
Pour info pour ceux qui ne sont pas alle voir, c'est bien un bug.
7.19.3/11 impose que toute lecture soit faite comme si on utilisait fgetc
et fgetc echoue si le marqueur de fin de fichier est mis.
Note historique: le comportement traditionnel etait bien celui que j'ai
observe sur Linux et Solaris mais la norme a toujours demande le
comportement que je trouve plus coherent.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
je viens de tester mais j'ai un resultat qui m'etonne,
Apres analyse, j'ai decide de poser la question sur comp.std.c.
Pour info pour ceux qui ne sont pas alle voir, c'est bien un bug. 7.19.3/11 impose que toute lecture soit faite comme si on utilisait fgetc et fgetc echoue si le marqueur de fin de fichier est mis.
Note historique: le comportement traditionnel etait bien celui que j'ai observe sur Linux et Solaris mais la norme a toujours demande le comportement que je trouve plus coherent.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
