O_TEXT, en environnement microsoft

Le
O_TEXT
Lors de l'ouverture d'un fichier avec open et O_TEXT, dans un
environnement microsoft, la lecture avec la fonction read, est faite en
mode texte.

Que signifie exactement mode texte?

Comment cela est-il géré en lecture?

Comment cela est-il géré en écriture?

Le mode texte a t-il un impact sur les fonction indiquant la position
dans le fichier? Si oui, lequel?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Antoine Leca
Le #997712
En news:fh1eg5$2cun$, O_TEXT va escriure:
Lors de l'ouverture d'un fichier avec open et O_TEXT, dans un
environnement microsoft, la lecture avec la fonction read, est faite
en mode texte.

Que signifie exactement mode texte?


Le mode normal des fichiers, qui sont censé contenir du texte.
Cela s'oppose au mode binaire [ajouter un "b" dans l'appel avec
fopen(, "rb")].

<HS>
En fait, O_TEXT est une tautologie, qui s'oppose à O_BINARY.
O_BINARY est à son tour un truc des compilos DOS et dérivés, qui les fait
ressembler aux compilos Unix, où il n'y a pas de distinction entre mode
binaire et mode texte, et donc où beaucoup de programmes sont mal écrits en
ce sens que les programmeurs ont « oublié » le "rb" pour lire les fichiers
binaires; pour porter facilement ces programmes, on positionne par défaut le
mode à O_BINARY, et cela marche tout seul.
</HS>


Comment cela est-il géré en lecture?


Cela dépend de l'implémentation. La manière simple est d'ignorer purement et
simplement le caractère 0x0D (CR) en lecture. D'autres algorithmes plus
perfectionnés et moins bêtes existent.


Comment cela est-il géré en écriture?


Cela dépend de l'implémentation. La manière simple est de faire les sorties
caractère par caractère, et à chaque fois que l'on voit un 'n' (0x0A), on
émet ensuite un 0x0D ; mais les performances sont... pas très bonnes.
Une autre possibilité est de scanner d'abord pour voir s'il y a un 0x0A,
envoyer toute la ligne y compris le 0x0A, puis le caractère 0x0A. Une autre
possibilité est de recopier dans un tampon à part en insérant à la volée des
0x0D, puis d'écrire tout le tampon d'un seul coup.


Le mode texte a t-il un impact sur les fonction indiquant la position
dans le fichier? Si oui, lequel?


Il y a un impact :-)
En C standard, l'utilisation des « fonctions indiquant la position » est
restreinte lorsqu'on est en mode texte. Seul est garanti la séquence

sauve = ftell(f);

/* plus loin */
fseek(f, sauve, SEEK_SET);

(et idem avec fgetpos()/fsetpos(), évidemment).

De plus, en mode texte, la valeur mise dans sauve n'a pas de sens en soi.


Antoine

Eric Levenez
Le #997711
Le 9/11/07 19:38, dans
En news:fh1eg5$2cun$, O_TEXT va escriure:

Comment cela est-il géré en lecture?


Cela dépend de l'implémentation. La manière simple est d'ignorer purement et
simplement le caractère 0x0D (CR) en lecture. D'autres algorithmes plus
perfectionnés et moins bêtes existent.


Et tout ce qui suit un Ctrl-Z est ignoré, non ?

--
Éric Lévénez -- Unix is not only an OS, it's a way of life.


Jean-Marc Bourguet
Le #999261
Eric Levenez
Le 9/11/07 19:38, dans
En news:fh1eg5$2cun$, O_TEXT va escriure:

Comment cela est-il géré en lecture?


Cela dépend de l'implémentation. La manière simple est d'ignorer purement et
simplement le caractère 0x0D (CR) en lecture. D'autres algorithmes plus
perfectionnés et moins bêtes existent.


Et tout ce qui suit un Ctrl-Z est ignoré, non ?


Pas sur. J'ai cru comprendre que Microsoft etait plutot schizophrene sur
ce genre de points (autrement dit il n'y a pas de definition officielle de
ce qu'etait un fichier au format texte et des comportements differents
suivant les programmes; le meme genre de probleme se pose pour savoir sur
la paire CR-LF est un terminateur de ligne ou un separateur de ligne).

Mais mon experience des logiciels de Microsoft est de plus en plus celle
d'un utilisateur "de base".

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



Antoine Leca
Le #999258
En news:C35A6B2F.BB1AC%, Eric Levenez va escriure:
Le 9/11/07 19:38, dans
En news:fh1eg5$2cun$, O_TEXT va escriure:

Comment cela est-il géré en lecture?


Cela dépend de l'implémentation. La manière simple est d'ignorer
purement et simplement le caractère 0x0D (CR) en lecture. D'autres
algorithmes plus perfectionnés et moins bêtes existent.


Et tout ce qui suit un Ctrl-Z est ignoré, non ?


Tiens, j'l'avais oublié, c'lui-là. >:-|
Bon, comme je l'écrivais, « cela dépend de l'implémentation » :-).
J'en connais qui ne considère les 'x1A' uniquement si on est à moins de 128
octets de la fin du fichier (convention MS-DOS au sens strict), d'autres qui
coupent (EOF) au premier rencontré comme l'écrit Éric, d'autres qui
négligent (ignoré, au même titre que 'x0D' et probablement que '' NUL,
pendant qu'on y est).

Du point de vue de la norme, 'x1A' (qui n'est pas un caractère imprimable,
ni un des caractères « format effector » attendu dans un flux texte, cf.
7.19.2p2) ne peut pas être utilisé de manière fiable dans un fichier ouvert
en mode non-binaire. Donc un fichier « type MS-DOS compatible CP/M », avec
des 'x1A' de remplissage à la fin pour atteindre la prochaine frontière de
128 octets, sera traité toujours de la même manière. Idem pour le fichier
« type MS-DOS 1 », avec un seul 'x1A' avant la fin de fichier. Tout autre
utilisation de 'x1A' peut entraìner des problèmes.


Antoine



Publicité
Poster une réponse
Anonyme