sizeof(char) == sizeof(int)

Le
Marc Boyer
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

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Marc Bourguet
Le #1147074
Marc Boyer
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
Le #1147073
On 2008-02-28, Jean-Marc Bourguet
Marc Boyer
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
Le #1159243
Marc Boyer
On 2008-02-28, Jean-Marc Bourguet
Marc Boyer
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
Le #1216450
"Marc Boyer" 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.

Jean-Marc Bourguet
Le #1235636
"Charlie Gordon"
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
Le #1236126
Dans l'article Jean-Marc Bourguet
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.

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Vincent Lefevre
Le #1237144
Dans l'article Jean-Marc Bourguet
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.

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Jean-Marc Bourguet
Le #1237143
Vincent Lefevre
Dans l'article Jean-Marc Bourguet
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
Le #1239133
Jean-Marc Bourguet
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
Le #1250660
Jean-Marc Bourguet
Jean-Marc Bourguet
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


Publicité
Poster une réponse
Anonyme