lecture d'un fichier Hexa

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:vbaohvg2iuu22jcl91fg2aqkkicv3lsqp5@4ax.com...

On 21 Jul 2003 02:54:05 -0700, kanze@gabi-soft.fr wrote:

En revanche, je ne sais pas si j'utiliserais le mot « ancien », parce
que c'est toujours supporté sous les dernières versions de VC++ sous les
dernières Windows, je crois. Si tu ouvres un fichier en mode texte, et
le fichier contient un 0x1A, la lecture s'arrête là.

Y a-t-il une raison valable à cela ? La norme en parle-t-elle ?

Peut-être peut-on trouver des raisons dans les discussions passées (un peu
anciennes déjà) sur les possibilités ou impossibilités de connaitre
réellement la taille d'un fichier avant de l'avoir complètement lu ?

De fait, dans un système ou tout peut être considéré comme fichier, y
compris la console, il faut bien un moyen d'en indiquer la fin dans la
mesure où on ne peut pas connaitre sa taille à l'avance, me semble-t-il...

Chris

On Mon, 21 Jul 2003 20:52:10 +0200, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:

Y a-t-il une raison valable à cela ? La norme en parle-t-elle ?

Peut-être peut-on trouver des raisons dans les discussions passées (un peu
anciennes déjà) sur les possibilités ou impossibilités de connaitre
réellement la taille d'un fichier avant de l'avoir complètement lu ?

Le langage C++ ne peut calculer la taille d'un fichier sans l'avoir
parcouru. L'OS, par contre, le peut très bien.

De fait, dans un système ou tout peut être considéré comme fichier, y
compris la console, il faut bien un moyen d'en indiquer la fin dans la
mesure où on ne peut pas connaitre sa taille à l'avance, me semble-t-il...

Même chose ici : c'est au système d'exploitation de se débrouiller
pour savoir quand le fichier se termine. Le langage n'a pas à s'en
préoccuper -- quand le programme essaie de lire des octets alors que
la fin du fichier est atteinte, le système renvoie une erreur, que le
langage se contente de répercuter vers le programme.

Tu remarqueras d'ailleurs que le EOF des système Microsoft (et
peut-être aussi Unix), qui sert à indiquer "à la main" la fin de
l'entrée sur la console, est le caractère ^Z (0x1A je suppose), tandis
que le EOF du langage est -1.



--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:pvnohvs4vnuofujcs1v3i6hcp21kdha922@4ax.com...

On Mon, 21 Jul 2003 20:52:10 +0200, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:

Y a-t-il une raison valable à cela ? La norme en parle-t-elle ?

Peut-être peut-on trouver des raisons dans les discussions passées (un
peu

anciennes déjà) sur les possibilités ou impossibilités de connaitre
réellement la taille d'un fichier avant de l'avoir complètement lu ?

Le langage C++ ne peut calculer la taille d'un fichier sans l'avoir
parcouru. L'OS, par contre, le peut très bien.

S'il en a une, et si elle est connue à l'avance (ce qui est le cas des
fichiers sur disque, bien entendu)

De fait, dans un système ou tout peut être considéré comme fichier, y
compris la console, il faut bien un moyen d'en indiquer la fin dans la
mesure où on ne peut pas connaitre sa taille à l'avance, me
semble-t-il...

Même chose ici : c'est au système d'exploitation de se débrouiller
pour savoir quand le fichier se termine. Le langage n'a pas à s'en
préoccuper -- quand le programme essaie de lire des octets alors que
la fin du fichier est atteinte, le système renvoie une erreur, que le
langage se contente de répercuter vers le programme.

Et comment en informe-t-il l'application ?

Tu remarqueras d'ailleurs que le EOF des système Microsoft (et
peut-être aussi Unix), qui sert à indiquer "à la main" la fin de
l'entrée sur la console, est le caractère ^Z (0x1A je suppose), tandis
que le EOF du langage est -1.

Au même titre que c'était '$' pour désigner une fin de chaine sur les
processeurs intel et non pas ''. C'est juste une question de convention,
celà ne veut pas dire pour autant que c'est inutile...

Chris

Prenons le code suivant :

void f (istream& is)
{
std::string ligne;
while (getline (is, ligne));
}

A chaque parcours de la boucle :

1- le programme demande au langage (plus précisément à la SL) de lire
une ligne
2- le langage demande à l'OS de lui envoyer un octet
-> si le fichier est terminé, l'OS refuse, et le langage met à 1
le bit qui va bien dans le istream, puis renvoie la main au programme
-> si le fichier n'est pas terminé, l'OS accepte ; le langage
examine cet octet, et s'il reconnaît l'octet de fin de ligne, il
renvoie la main au programme. Sinon, il revient en 2.

La détection de fin de fichier est la tâche de l'OS. Sur systèmes
"classiques" (Win/Unix), l'OS détecte la fin du fichier en comptant le
nombre d'octets lus s'il s'agit d'un vrai fichier, ou détecte la fin
du programme dans le cas d'un pipe, ou attend un "^Z" (0x1A) s'il
s'agit de la console. Le langage n'a à aucun moment la tâche de
s'occuper d'un éventuel caractère 0x1A.



--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html

Fabien LE LEZ <gramster@gramster.com> writes:

On 21 Jul 2003 02:54:05 -0700, kanze@gabi-soft.fr wrote:

En revanche, je ne sais pas si j'utiliserais le mot « ancien », parce
que c'est toujours supporté sous les dernières versions de VC++ sous les
dernières Windows, je crois. Si tu ouvres un fichier en mode texte, et
le fichier contient un 0x1A, la lecture s'arrête là.

Y a-t-il une raison valable à cela ?

Windows est compatible avec DOS et DOS avec CPM et CPM ne connaissait
pas la taille exacte des fichiers.

COPY et TYPE s'arrete (s'arretait?) au premier SUB. Avantage, mettre
un SUB dans la signature des fichiers binaires evite d'envoyer par
erreur a l'ecran des conneries (par exemple la signature des PGN
comprend un SUB exactement pour cette raison, de meme elle est concue
pour detecter des problemes comme la conversion des CR-LF en LF et des
LF isoles en CR, le stripping du 8ieme bit, l'inversion de bytes,...)

La norme en parle-t-elle ?

De quoi, du fait que pour Windows un ficher texte se termine au
premier SUB? Pourquoi elle en parlerait, ca depend de l'OS et la
norme doit permettre de gerer toute forme de fichier texte (ceux qui
sont des enregistrements de tailles fixes, ceux dont la structure est
opaque et accessible ligne par ligne, ceux dont toute ligne commence
par la taille,...)

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Fabien LE LEZ <gramster@gramster.com> writes:

On Mon, 21 Jul 2003 20:52:10 +0200, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:

Y a-t-il une raison valable à cela ? La norme en parle-t-elle ?

Peut-être peut-on trouver des raisons dans les discussions passées (un peu
anciennes déjà) sur les possibilités ou impossibilités de connaitre
réellement la taille d'un fichier avant de l'avoir complètement lu ?

Le langage C++ ne peut calculer la taille d'un fichier sans l'avoir
parcouru. L'OS, par contre, le peut très bien.

Il faut surtout d'abord se mettre d'accord sur la definition de
taille. Si ton fichier est encode en UTF-8, je me demande quel OS te
permet d'acceder a la taille du fichier pour toute definition utile...

De fait, dans un système ou tout peut être considéré comme fichier,
y compris la console, il faut bien un moyen d'en indiquer la fin
dans la mesure où on ne peut pas connaitre sa taille à l'avance, me
semble-t-il...

Même chose ici : c'est au système d'exploitation de se débrouiller
pour savoir quand le fichier se termine. Le langage n'a pas à s'en
préoccuper

Mais ici C++ ne s'en preoccupe pas. Le systeme (Windows) definit que
la fin d'un fichier texte est au premier SUB, la bibliotheque standard
C++ sous Windows implemente la specification.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Fabien LE LEZ <gramster@gramster.com> writes:

On Mon, 21 Jul 2003 20:52:10 +0200, "Christophe Lephay"
Tu remarqueras d'ailleurs que le EOF des système Microsoft (et
peut-être aussi Unix), qui sert à indiquer "à la main" la fin de
l'entrée sur la console, est le caractère ^Z (0x1A je suppose),

Les choses sont beaucoup plus compliquees que ca sous unix.

La fin d'un fichier est detectee par une lecture de longueur nulle.
L'OS n'interdit pas de retenter de lire apres qu'il a signaler la fin
du fichier (par exemple c'est ce que fait tail -f), apres tout un
autre process peut ecrire dans le fichier et l'agrandir.

Dans le cas d'un terminal, il peut etre dans deux modes. En mode
"raw", les caracteres sont passes tel quels et il n'y a pas de fin de
fichier. En mode "cooked", le gestionnaire de terminal (qui fait
partie de l'OS), interprete certains caracteres (par exemple pour
permettre d'editer la ligne) et ne passe normalement que des lignes
completes; on peut changer les caracteres pour chaque signification
(par exemple on peut utiliser le caractere qu'on veut pour effacer le
dernier caractere, les choix courant sont BACKSPACE et DEL). Un des
caracteres interpretes par le gestionnaire de terminal permet de lui
dire d'envoyer la ligne telle quelle sans attendre la fin (c'est
generalement ^D). Si on tape ce caractere en debut de ligne, le
process lisant le terminal a une lecture de taille nulle, interpretee
donc comme une fin de fichier.

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

"Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:

Au même titre que c'était '$' pour désigner une fin de chaine sur les
processeurs intel et non pas ''.

Rien dans les processeurs intel n'est prevu pour designer une fin de
chaine. Tu confonds peut-etre avec le BIOS des PC ou certaines
"interruptions" utilisaient effectivement '$' pour marquer la fin de
chaines (mais si j'ai bonne memoire, ce n'etait pas le cas de toutes).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<pvnohvs4vnuofujcs1v3i6hcp21kdha922@4ax.com>...

On Mon, 21 Jul 2003 20:52:10 +0200, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:

Y a-t-il une raison valable à cela ? La norme en parle-t-elle ?

Peut-être peut-on trouver des raisons dans les discussions passées
(un peu anciennes déjà) sur les possibilités ou impossibilités de
connaitre réellement la taille d'un fichier avant de l'avoir
complètement lu ?

Le langage C++ ne peut calculer la taille d'un fichier sans l'avoir
parcouru. L'OS, par contre, le peut très bien.

Pour quelle définition de taille ? L'OS doit bien savoir combien de
place disque le fichier occupe. Au delà de ça, certains OS on la notion
du nombre d'octets qu'occupe le fichier. Nombre qu'il a une
signification tout à fait rélatif, sans forcement grand rapport avec le
nombre d'octets on peut lire dans un programme C++.

De fait, dans un système ou tout peut être considéré comme fichier, y
compris la console, il faut bien un moyen d'en indiquer la fin dans
la mesure où on ne peut pas connaitre sa taille à l'avance, me
semble-t-il...

Même chose ici : c'est au système d'exploitation de se débrouiller
pour savoir quand le fichier se termine. Le langage n'a pas à s'en
préoccuper -- quand le programme essaie de lire des octets alors que
la fin du fichier est atteinte, le système renvoie une erreur, que le
langage se contente de répercuter vers le programme.

C'est plus compliqué que ça. C'est au niveau de l'implémentation de la
bibliothèque standard qu'il faut décider comment interpréter ce que
donne l'OS. Par exemple, l'OS Unix n'a pas de fin fichier. Tu as
simplement une position dans le fichier, à partir de la quelle on
cherche à lire. Ainsi que des règles qui arrête la lecture -- règles qui
dépend du type du « fichier ». (Elles sont différentes pour une pipe, un
fichier standard, et un clavier, par exemple.) Par convention, mais l'OS
n'y est pour rien, quand la lecture s'arrête sans qu'aucun octet n'a été
lu, l'application interprète une fin de fichier. Mais c'est très
arbitraire, et il existe des programmes qui continue à lire même quand
ils ont vu « fin de fichier ».

Dans le contexte de C++, ça pose même un problème, parce que les
implémentations de std::filebuf que j'ai vu ne mémorisent pas quand
elles ont vue une fin de fichier. Ce qui veut dire que deux appels
successifs à filebuf::sgetc() peuvent renvoyer des choses différentes.

Tu remarqueras d'ailleurs que le EOF des système Microsoft (et
peut-être aussi Unix), qui sert à indiquer "à la main" la fin de
l'entrée sur la console, est le caractère ^Z (0x1A je suppose), tandis
que le EOF du langage est -1.

Voir ci-dessus. Il n'y a pas de « fin de fichier » au niveau du noyau
Unix (sauf peut-être pour des streams, où il y a une signalisation hors
bande). Des entrées claviers sont par défaut bufferisées ligne (dans le
système) ; un EOT (cntl-D) force le retour d'une lecture immédiate, avec
ce qu'il y a déjà dans le buffer, et rien de plus. Ce qui fait que la
plupart des applications traiteraient un cntl-D du clavier comme une fin
de fichier. (Mais essaie avec « tail -f ».)

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<olqohvckgma03uvd5olavaq44od04hr0qj@4ax.com>...

La détection de fin de fichier est la tâche de l'OS. Sur systèmes
"classiques" (Win/Unix), l'OS détecte la fin du fichier en comptant le
nombre d'octets lus s'il s'agit d'un vrai fichier, ou détecte la fin
du programme dans le cas d'un pipe, ou attend un "^Z" (0x1A) s'il
s'agit de la console. Le langage n'a à aucun moment la tâche de
s'occuper d'un éventuel caractère 0x1A.

Je ne suis pas si sûr. Unix n'a pas vraiment la notion d'une fin de
fichier. (Je crois d'ailleurs que la même chose vaut pour Windows.)
N'oublie pas que sous Unix, le clavier ou une pipe est un « fichier ».
D'ailleurs, dès qu'on a un système multi-processus, ça veut dire quoi,
la fin d'un fichier ?

À la fin, la bibliothèque standard fait un appel au système. À la suite,
c'est à lui d'interpréter le résultat, et de décider si elle veut le
considérer comme fin de fichier, ou quoi. La tradition sous Unix, c'est
que quand un essai de lecture revient avec zéro octets lus, c'est une
fin de fichier. Quelque soit la raison pourquoi on est revenu sans rien
avoir lu -- une erreur de lecture physique est traitée comme une fin de
fichier normal, par exemple.

À chaque système, on définit des conventions.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16