Jean-Marc Bourguet a écrit :(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-) en particulier avec la nécessité de supporter les
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Jean-Marc Bourguet a écrit :
(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-) en particulier avec la nécessité de supporter les
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Jean-Marc Bourguet a écrit :(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-) en particulier avec la nécessité de supporter les
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Samuel DEVULDER écrivit :Je ne comprends pas bien.
Si je veux faire rire, j'isole cette phrase...Je ne comprends pas bien. Tu aurait voulu quoi au juste?
Ce que JE n'arrive pas à comprendre, c'est le propos de contester
l'utilisation de EOF, à remplacer par feof(),
fonctions la valeur retournée par la fonction d'ES dans le cas similaire
est NULL ou 0, alors même que l'utilisation de cette fonction peut
parfois amener des résultats incorrects.
Par exemple, si on reprend ta formulation légèrement modifiée :
s = fgets(s, sizeof s, FLUX);
if(feof(FLUX)) break;
Si la fin de fichier n'est pas « protégée » par un n, elle va être
mangée par le break... Un joli bogue silencieux, facile à oublier en
test, en attente d'un jeu de données imprévu pour le faire monter...
Qu'en fin de fichier scanf() retourne un buffer non rempli? C'est
justement le cas si tu lis passé le feof()==true.
Dans l'essai de Jean-Marc, scanf() a lu "tutu", et en même temps touché
la fin du fichier, donc l'indicateur est passé à 1 ; puis a rempli le
tampon avec tutu comme demandé.
va réessayer de lire, étant positionné à la fin du fichier cela va
échouer et donc retournera enfin EOF : mais à l'itération précédente il
pourra/devra traiter le tutu.J'ai un peu le sentiment que l'erreur, ou le hiatus, est de considérer
que scanf() retourne un truc en relation directe avec la fin de fichier.
Voilà. C'est comme cela que fonctionne le C : la fin de fichier est une
condition « anormale », à traiter en sortie de boucle.
Jean-Marc Bourguet a écrit :(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-)
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Samuel DEVULDER écrivit :
Je ne comprends pas bien.
Si je veux faire rire, j'isole cette phrase...
Je ne comprends pas bien. Tu aurait voulu quoi au juste?
Ce que JE n'arrive pas à comprendre, c'est le propos de contester
l'utilisation de EOF, à remplacer par feof(),
fonctions la valeur retournée par la fonction d'ES dans le cas similaire
est NULL ou 0, alors même que l'utilisation de cette fonction peut
parfois amener des résultats incorrects.
Par exemple, si on reprend ta formulation légèrement modifiée :
s = fgets(s, sizeof s, FLUX);
if(feof(FLUX)) break;
Si la fin de fichier n'est pas « protégée » par un n, elle va être
mangée par le break... Un joli bogue silencieux, facile à oublier en
test, en attente d'un jeu de données imprévu pour le faire monter...
Qu'en fin de fichier scanf() retourne un buffer non rempli? C'est
justement le cas si tu lis passé le feof()==true.
Dans l'essai de Jean-Marc, scanf() a lu "tutu", et en même temps touché
la fin du fichier, donc l'indicateur est passé à 1 ; puis a rempli le
tampon avec tutu comme demandé.
va réessayer de lire, étant positionné à la fin du fichier cela va
échouer et donc retournera enfin EOF : mais à l'itération précédente il
pourra/devra traiter le tutu.
J'ai un peu le sentiment que l'erreur, ou le hiatus, est de considérer
que scanf() retourne un truc en relation directe avec la fin de fichier.
Voilà. C'est comme cela que fonctionne le C : la fin de fichier est une
condition « anormale », à traiter en sortie de boucle.
Jean-Marc Bourguet a écrit :
(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-)
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Samuel DEVULDER écrivit :Je ne comprends pas bien.
Si je veux faire rire, j'isole cette phrase...Je ne comprends pas bien. Tu aurait voulu quoi au juste?
Ce que JE n'arrive pas à comprendre, c'est le propos de contester
l'utilisation de EOF, à remplacer par feof(),
fonctions la valeur retournée par la fonction d'ES dans le cas similaire
est NULL ou 0, alors même que l'utilisation de cette fonction peut
parfois amener des résultats incorrects.
Par exemple, si on reprend ta formulation légèrement modifiée :
s = fgets(s, sizeof s, FLUX);
if(feof(FLUX)) break;
Si la fin de fichier n'est pas « protégée » par un n, elle va être
mangée par le break... Un joli bogue silencieux, facile à oublier en
test, en attente d'un jeu de données imprévu pour le faire monter...
Qu'en fin de fichier scanf() retourne un buffer non rempli? C'est
justement le cas si tu lis passé le feof()==true.
Dans l'essai de Jean-Marc, scanf() a lu "tutu", et en même temps touché
la fin du fichier, donc l'indicateur est passé à 1 ; puis a rempli le
tampon avec tutu comme demandé.
va réessayer de lire, étant positionné à la fin du fichier cela va
échouer et donc retournera enfin EOF : mais à l'itération précédente il
pourra/devra traiter le tutu.J'ai un peu le sentiment que l'erreur, ou le hiatus, est de considérer
que scanf() retourne un truc en relation directe avec la fin de fichier.
Voilà. C'est comme cela que fonctionne le C : la fin de fichier est une
condition « anormale », à traiter en sortie de boucle.
Jean-Marc Bourguet a écrit :(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-)
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Antoine Leca writes:Jean-Marc Bourguet a écrit :(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-) en particulier avec la nécessité de supporter les
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Le texte de fread est
The fread function returns the number of elements successfully read,
which may be less than nmemb if a read error or end-of-file is
encountered.
Je comprends ton interprétation et elle me semble la bonne. En passant, un
autre cas plus courant, celui des flux interactifs, montre qu'elle est
préférable.
Antoine Leca <root@localhost.invalid> writes:
Jean-Marc Bourguet a écrit :
(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-) en particulier avec la nécessité de supporter les
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Le texte de fread est
The fread function returns the number of elements successfully read,
which may be less than nmemb if a read error or end-of-file is
encountered.
Je comprends ton interprétation et elle me semble la bonne. En passant, un
autre cas plus courant, celui des flux interactifs, montre qu'elle est
préférable.
Antoine Leca writes:Jean-Marc Bourguet a écrit :(Avec fread il faut comparer la valeur retournee avec la
taille du buffer, si elles sont differentes, il y a fin de fichier ou
erreur de lecture; c'est avec read(2) sous Unix qu'on peut avoir des
lectures partielles)
Je ne suis pas certain. À la différence de fwrite() qui spécifie que
The fwrite function returns [...] which will be
less than nmemb only if a write error is encountered.
^^^^
le texte pour fread n'a pas ce "only". Et je serais TRÈS surpris que ce
soit un oubli :-) en particulier avec la nécessité de supporter les
fichiers « à la MSDOS » où il faut après lecture convertir les CR+LF en
n, et aussi les fichiers « à la mainframe » où ce sont les de
bourrage en fin de record qui sont éliminés, même sur un fichier "rb"...
Le texte de fread est
The fread function returns the number of elements successfully read,
which may be less than nmemb if a read error or end-of-file is
encountered.
Je comprends ton interprétation et elle me semble la bonne. En passant, un
autre cas plus courant, celui des flux interactifs, montre qu'elle est
préférable.
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
vient d'un document d'introduction à l'assembleur pour Linux que je ne
peux lire que pendant la pause à midi ou tard en fin de journée.... Je
sais que int c'est pour interruption... et que ça concernerait des
registres comme eax ou ebx ... -merci
Antoine Leca a écrit :Par exemple, si on reprend ta formulation légèrement modifiée :
s = fgets(s, sizeof s, FLUX);
Et le test à NULL? Ca change tout.
if(fgets(s, sizeof s, FLUX)) {traitement}if(feof(FLUX)) break;
En même temps, fread() lit un truc bufferisé
Antoine Leca a écrit :
Par exemple, si on reprend ta formulation légèrement modifiée :
s = fgets(s, sizeof s, FLUX);
Et le test à NULL? Ca change tout.
if(fgets(s, sizeof s, FLUX)) {traitement}
if(feof(FLUX)) break;
En même temps, fread() lit un truc bufferisé
Antoine Leca a écrit :Par exemple, si on reprend ta formulation légèrement modifiée :
s = fgets(s, sizeof s, FLUX);
Et le test à NULL? Ca change tout.
if(fgets(s, sizeof s, FLUX)) {traitement}if(feof(FLUX)) break;
En même temps, fread() lit un truc bufferisé
a raconté :Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
int 0x80 permet de déclencher un appel à une fonction de la
kernelle Linux,
donc oui, l'appel système write passera par l'instruction int 0x80.
bpascal123@googlemail.com a raconté :
Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
int 0x80 permet de déclencher un appel à une fonction de la
kernelle Linux,
donc oui, l'appel système write passera par l'instruction int 0x80.
a raconté :Est-ce qu'il y a un lien entre l'affichage d'un caractère à l'écran et
cette commande assembleur : int 0x80 ou quelque chose comme ça... Ca
int 0x80 permet de déclencher un appel à une fonction de la
kernelle Linux,
donc oui, l'appel système write passera par l'instruction int 0x80.
