Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Positionnement avec fseek
Je lis un fichier physique créé par blocs note auquel je dois accéder par un index.chaque enreg est une chaine de caracteres.
Donc j'utilise fseek puis fgets mais ça ne marche pas du tout, il y a toujours un décalage.
Je n'y comprends rien
Quelqu'un a une idée ? Merci
Il faudrait que tu postes ton code, car on ne peut pas deviner où est le problème sinon.
fseek ne marche pour des fichiers texte que sous certaines conditions restrictives :
- le déplacement doit être 0 ou une valeur retournée par ftell
- le paramètre de positionnement doit être SEEK_SET
Si tu dois te positionner sur une ligne d'un fichier texte, utilise fgets pour sauter les lignes précédentes (Et là tu pourras faire un ftell si tu as besoin de te repositionner plus tard sur cette même ligne)
ok j'essaye ça. Merci
Ca sort d'où ?????????fseek ne marche pour des fichiers texte que sous certaines conditions restrictives :
- le déplacement doit être 0 ou une valeur retournée par ftell
- le paramètre de positionnement doit être SEEK_SET
de la norme!Envoyé par plxpy
7.19.9.2 The fseek function
Synopsis
1 #include <stdio.h>
int fseek(FILE *stream, long int offset, int whence);
Description
2 The fseek function sets the file position indicator for the stream pointed to by stream. If a read or write error occurs, the error indicator for the stream is set and fseek fails.
3 For a binary stream, the newposition, measured in characters from the beginning of the file, is obtained by adding offset to the position specified by whence.The specified position is the beginning of the file if whence is SEEK_SET,the current value of the file position indicator if SEEK_CUR,orend-of-file if SEEK_END.Abinary stream need not meaningfully support fseek calls with a whence value of SEEK_END.
4 For a text stream, either offset shall be zero, or offset shall be a value returned by an earlier successful call to the ftell function on a stream associated with the same file and whence shall be SEEK_SET.
5 After determining the newposition, a successful call to the fseek function undoes any effects of the ungetc function on the stream, clears the end-of-file indicator for the stream, and then establishes the newposition. After asuccessful fseek call, the next operation on an update stream may be either input or output.
Returns
6 The fseek function returns nonzero only for a request that cannot be satisfied.
Effectivement, la norme qui, je l'avoue, n'est pas mon livre de chevet, indique bien cela mais les raisons de cette régression m'échappent quelque peu (effet de bord pervers de la normalisation poussée à l'extrême ?).
Personnellement, avec mes compilos GNU, je continuerai à faire des fseek dans tous les sens, depuis le début, l'endroit où je suis ou la fin quand cela est nécessaire, fichier texte ou pas !
La raison est pourtant très simple: Il est assez difficile de gérer les offsets et cie sur un système utilisant CR+LF comme fin de ligne (car la lecture d'un fichier en mode texte fait la conversion à-la-volée vers LF).
Si l'on voulait avancer de 10 "octets" vers l'avant, doit-il s'agir d'octets réels ou d'octets virtuels?
En clair, ce n'est pas une question d'extension GNU, mais de système: Tu auras des problèmes sous MinGW si tu agis en dépit de la norme.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
C'est ton choix de développer des programmes non portables.Personnellement, avec mes compilos GNU, je continuerai à faire des fseek dans tous les sens, depuis le début, l'endroit où je suis ou la fin quand cela est nécessaire, fichier texte ou pas !
Je crois que cela est dû à la définition très souple des fichiers texte qui fait que la représentation du contenu d'un fichier texte dans le programme peut différer du contenu physique du fichier. Alors, sans précautions, on ne sait pas trop où on se situe dans le fichier physique.
Par compléter, la norme dit :
7.19.2 Streams
....
2 A text stream is an ordered sequence of characters composed into lines, each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined. Characters may have to be added, altered, or deleted on input and output to conform to differing conventions for representing text in the host environment. Thus, there need not be a one-to-one correspondence between the characters in a stream and those in the external representation. Data read in from a text stream will necessarily compare equal to the data that were earlier written out to that stream only if: the data consist only of printing characters and the control characters horizontal tab and new-line; no new-line character is immediately preceded by space characters; and the last character is a new-line character.
Whether space characters that are written out immediately before a new-line character appear when read in is implementation-defined.
Bon ça marche avec ftell et fseek. Et apparemment ça ne marche pas autrement.
En plus il faut faire attention avec l'éditeur du .txt (par ex bloc notes) car si on s'amuse à rajouter des blancs à la fin de la chaine de caracteres, cela peut compter comme des nouveaux enregistrements...
Merci à tous de votre aide
Répondre avec citation
Partager