Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Antoine Leca
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
En news:fh1eg5$2cun$3@biggoron.nerim.net, 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.
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 9/11/07 19:38, dans <fh29f7$3gm$, « Antoine Leca » a écrit :
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 -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 9/11/07 19:38, dans <fh29f7$3gm$1@shakotay.alphanet.ch>, « Antoine Leca »
<root@localhost.invalid> a écrit :
En news:fh1eg5$2cun$3@biggoron.nerim.net, 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 -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 9/11/07 19:38, dans <fh29f7$3gm$, « Antoine Leca » a écrit :
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 -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Jean-Marc Bourguet
Eric Levenez writes:
Le 9/11/07 19:38, dans <fh29f7$3gm$, « Antoine Leca » a écrit :
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
Eric Levenez <usenet@levenez.com> writes:
Le 9/11/07 19:38, dans <fh29f7$3gm$1@shakotay.alphanet.ch>, « Antoine Leca »
<root@localhost.invalid> a écrit :
En news:fh1eg5$2cun$3@biggoron.nerim.net, 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
Le 9/11/07 19:38, dans <fh29f7$3gm$, « Antoine Leca » a écrit :
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
En news:C35A6B2F.BB1AC%, Eric Levenez va escriure:
Le 9/11/07 19:38, dans <fh29f7$3gm$, « Antoine
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
En news:C35A6B2F.BB1AC%usenet@levenez.com, Eric Levenez va escriure:
Le 9/11/07 19:38, dans <fh29f7$3gm$1@shakotay.alphanet.ch>, « Antoine
En news:fh1eg5$2cun$3@biggoron.nerim.net, 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.
En news:C35A6B2F.BB1AC%, Eric Levenez va escriure:
Le 9/11/07 19:38, dans <fh29f7$3gm$, « Antoine
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.
