Je veux lire un fichier dans un format binaire bien documenté, or la
documentation de ce format me dit que toutes les valeurs numériques sont
stockées en "network byte order", c'est-à-dire big endian si j'ai bien
compris.
Pour lire ces données numériques, j'ai donc pensé aux fonctions de la
série htonl, nltoh etc. dont j'ai entendu parler ici. J'ai donc lu les
manpages de ces fonctions, et deux problèmes se posent à moi :
1/ ce sont des fonctions de la norme BSD.
2/ elles ne permettent de traduire que des types entiers et non des
flottants.
Je me demandais donc si vous connaissiez une autre alternative pour
effectuer la traduction, ou bien si je vais être obligé d'écrire mes
propres routines de conversions.
| Jean-Marc Bourguet writes: | | |> "Antoine Leca" writes: | | |> > Ce que tu veux, c'est optimiser ta routine de lecture de | |> > flottants. Tu connais le format de ton fichier, c'est | |> > déjà cela. Mais connais-tu l'odre (gros ou petit boutien) | |> > des flottants sur ta machine ? Parce qu'il se trouve que | |> > ce n'est pas forcément le même que celui auquel tout le | |> > monde pense, celui des entiers. :-))) | | |> Je ne suis pas sûr du tout qu'il n'y ait que deux formats de | |> flottants qui se réclame de la norme IEEE. Gaby devrait | |> pouvoir commenter, il me semble qu'il a touché à cela pour | |> gcc... Si j'ai raison petit/grand boutien IEEE n'est pas | |> une information suffisante pour connaitre le format. | | En théorie ou en pratique ?
En pratique.
Lorsque je l'ai fait pour GCC, cela a été une joyeuse partie de « prend-moi la tête, je te mords la queue » :-/
Jean-Marc a raison.
Par exemple, pour les double, il faut savoir le byte-ordering des multi-mots ansi que le byte-ordering des mots (certains ARMs par exemple, ont le bon goût de mélanger les deux). Certains processeurs utilisent des bits de parité -- qu'on pourrait faussement croire être le bit de signe. Bref, il y a foultitude de représentations physiques qui implémentent le modèle mathématique énoncé dans IEEE-754.
| En principe, la norme IEEE précise les bits et leurs signification. Elle | ne précise pas l'ordre, ni même la représentation physique -- je crois | qu'une implémentation pourait mélanger les bits de l'exposant en plein | milieu de la mantisse, et sans doute complémenter chaque troisième bits. | Et y ajouter un bit de parité, pourquoi pas. | | Dans la pratique, je ne crois pas qu'on court beaucoup de risque. (Mais | je peux me trompé. Je me sers assez peu du flottant.)
Tu dois parler d'une pratique bien limitée. Même si on se limite à des machines moins « exotiques », on dénombre pléthore de représentations ; les HP par exemples, inversent allègrement les représentations des qNaNs avec celles des sNaNs.
Comme dirait von Neumann, « Computing is too important to be left to the computer scientists. »
-- Gaby
James Kanze <james.kanze@free.fr> writes:
| Jean-Marc Bourguet <jm@bourguet.org> writes:
|
| |> "Antoine Leca" <root@localhost.gov> writes:
|
| |> > Ce que tu veux, c'est optimiser ta routine de lecture de
| |> > flottants. Tu connais le format de ton fichier, c'est
| |> > déjà cela. Mais connais-tu l'odre (gros ou petit boutien)
| |> > des flottants sur ta machine ? Parce qu'il se trouve que
| |> > ce n'est pas forcément le même que celui auquel tout le
| |> > monde pense, celui des entiers. :-)))
|
| |> Je ne suis pas sûr du tout qu'il n'y ait que deux formats de
| |> flottants qui se réclame de la norme IEEE. Gaby devrait
| |> pouvoir commenter, il me semble qu'il a touché à cela pour
| |> gcc... Si j'ai raison petit/grand boutien IEEE n'est pas
| |> une information suffisante pour connaitre le format.
|
| En théorie ou en pratique ?
En pratique.
Lorsque je l'ai fait pour GCC, cela a été une joyeuse partie de «
prend-moi la tête, je te mords la queue » :-/
Jean-Marc a raison.
Par exemple, pour les double, il faut savoir le byte-ordering des
multi-mots ansi que le byte-ordering des mots (certains ARMs par
exemple, ont le bon goût de mélanger les deux). Certains processeurs
utilisent des bits de parité -- qu'on pourrait faussement croire être
le bit de signe. Bref, il y a foultitude de représentations physiques
qui implémentent le modèle mathématique énoncé dans IEEE-754.
| En principe, la norme IEEE précise les bits et leurs signification. Elle
| ne précise pas l'ordre, ni même la représentation physique -- je crois
| qu'une implémentation pourait mélanger les bits de l'exposant en plein
| milieu de la mantisse, et sans doute complémenter chaque troisième bits.
| Et y ajouter un bit de parité, pourquoi pas.
|
| Dans la pratique, je ne crois pas qu'on court beaucoup de risque. (Mais
| je peux me trompé. Je me sers assez peu du flottant.)
Tu dois parler d'une pratique bien limitée. Même si on se limite à des
machines moins « exotiques », on dénombre pléthore de représentations ;
les HP par exemples, inversent allègrement les représentations des
qNaNs avec celles des sNaNs.
Comme dirait von Neumann, « Computing is too important to be left to
the computer scientists. »
| Jean-Marc Bourguet writes: | | |> "Antoine Leca" writes: | | |> > Ce que tu veux, c'est optimiser ta routine de lecture de | |> > flottants. Tu connais le format de ton fichier, c'est | |> > déjà cela. Mais connais-tu l'odre (gros ou petit boutien) | |> > des flottants sur ta machine ? Parce qu'il se trouve que | |> > ce n'est pas forcément le même que celui auquel tout le | |> > monde pense, celui des entiers. :-))) | | |> Je ne suis pas sûr du tout qu'il n'y ait que deux formats de | |> flottants qui se réclame de la norme IEEE. Gaby devrait | |> pouvoir commenter, il me semble qu'il a touché à cela pour | |> gcc... Si j'ai raison petit/grand boutien IEEE n'est pas | |> une information suffisante pour connaitre le format. | | En théorie ou en pratique ?
En pratique.
Lorsque je l'ai fait pour GCC, cela a été une joyeuse partie de « prend-moi la tête, je te mords la queue » :-/
Jean-Marc a raison.
Par exemple, pour les double, il faut savoir le byte-ordering des multi-mots ansi que le byte-ordering des mots (certains ARMs par exemple, ont le bon goût de mélanger les deux). Certains processeurs utilisent des bits de parité -- qu'on pourrait faussement croire être le bit de signe. Bref, il y a foultitude de représentations physiques qui implémentent le modèle mathématique énoncé dans IEEE-754.
| En principe, la norme IEEE précise les bits et leurs signification. Elle | ne précise pas l'ordre, ni même la représentation physique -- je crois | qu'une implémentation pourait mélanger les bits de l'exposant en plein | milieu de la mantisse, et sans doute complémenter chaque troisième bits. | Et y ajouter un bit de parité, pourquoi pas. | | Dans la pratique, je ne crois pas qu'on court beaucoup de risque. (Mais | je peux me trompé. Je me sers assez peu du flottant.)
Tu dois parler d'une pratique bien limitée. Même si on se limite à des machines moins « exotiques », on dénombre pléthore de représentations ; les HP par exemples, inversent allègrement les représentations des qNaNs avec celles des sNaNs.
Comme dirait von Neumann, « Computing is too important to be left to the computer scientists. »
-- Gaby
Antoine Leca
En , Jean-Marc Bourguet va escriure:
"Antoine Leca" writes:
Ce que tu veux, c'est optimiser ta routine de lecture de flottants. Tu connais le format de ton fichier, c'est déjà cela. Mais connais-tu l'odre (gros ou petit boutien) des flottants sur ta machine ?
Je ne suis pas sûr du tout qu'il n'y ait que deux formats de flottants qui se réclame de la norme IEEE.
C'est bien ce que je voulais dire. Le fait de connaître le format du fichier externe est une chose (et je suis d'accord avec toi que c'est plus complexe que la simple notion de gros ou petit-boutien). De plus tu peux examiner le fichier reçu pour te faire une idée pratique de ce que tu vas recevoir.
Mais quand il s'agit de programmer, tu dois prévoir tout ce qui va arriver à ton joli programme (c'est cela le sel). Et c'est là que la diversité des plateformes entre en ligne de compte.
OK, « ta machine » ci-dessus est trompeur, puisque si on écrit un programme non portable pour une seule machine il « suffit » de regarder dedans pour savoir comment cela se comporte; et si on écrit du vraiment portable, évidemment la machine cible est une machine virtuelle union de toutes celles que l'on peut potentiellement rencontrer, ce n'est pas « sa » machine à lui.
Une autre chose qui me vient maintenant à l'idée (après avoir lu le post de Gaby) et qui est peut-être ce que tu voulais dire, c'est que bien que le fichier soit « normalisé », il y a des chances non négligeables de recevoir des « versions » légèrement incompatibles entre elles, parce que créées par la méthode brutale (ma machine est gros boutien, la norme dit gros boutien, donc fwrite et basta); évidemment les subtiles variations de format, du genre ordre des mots,... Donc la routine de lecture doit être « à l'épreuve des balles », et ne pas sauter même sur des séquences a priori invalides (si on comprend la norme d'une certaine façon) mais parfaitement possibles avec certaines machines et les écritures brutales.
Antoine
En 87fz30jmz2.fsf@news.bourguet.org, Jean-Marc Bourguet va escriure:
"Antoine Leca" <root@localhost.gov> writes:
Ce que tu veux, c'est optimiser ta routine de lecture de
flottants. Tu connais le format de ton fichier, c'est
déjà cela. Mais connais-tu l'odre (gros ou petit boutien)
des flottants sur ta machine ?
Je ne suis pas sûr du tout qu'il n'y ait que deux formats de
flottants qui se réclame de la norme IEEE.
C'est bien ce que je voulais dire.
Le fait de connaître le format du fichier externe est une chose (et je suis
d'accord avec toi que c'est plus complexe que la simple notion de gros ou
petit-boutien). De plus tu peux examiner le fichier reçu pour te faire une
idée pratique de ce que tu vas recevoir.
Mais quand il s'agit de programmer, tu dois prévoir tout ce qui va arriver à
ton joli programme (c'est cela le sel). Et c'est là que la diversité des
plateformes entre en ligne de compte.
OK, « ta machine » ci-dessus est trompeur, puisque si on écrit un programme
non portable pour une seule machine il « suffit » de regarder dedans pour
savoir comment cela se comporte; et si on écrit du vraiment portable,
évidemment la machine cible est une machine virtuelle union de toutes celles
que l'on peut potentiellement rencontrer, ce n'est pas « sa » machine à lui.
Une autre chose qui me vient maintenant à l'idée (après avoir lu le post de
Gaby) et qui est peut-être ce que tu voulais dire, c'est que bien que le
fichier soit « normalisé », il y a des chances non négligeables de recevoir
des « versions » légèrement incompatibles entre elles, parce que créées par
la méthode brutale (ma machine est gros boutien, la norme dit gros boutien,
donc fwrite et basta); évidemment les subtiles variations de format, du
genre ordre des mots,... Donc la routine de lecture doit être « à l'épreuve
des balles », et ne pas sauter même sur des séquences a priori invalides (si
on comprend la norme d'une certaine façon) mais parfaitement possibles avec
certaines machines et les écritures brutales.
Ce que tu veux, c'est optimiser ta routine de lecture de flottants. Tu connais le format de ton fichier, c'est déjà cela. Mais connais-tu l'odre (gros ou petit boutien) des flottants sur ta machine ?
Je ne suis pas sûr du tout qu'il n'y ait que deux formats de flottants qui se réclame de la norme IEEE.
C'est bien ce que je voulais dire. Le fait de connaître le format du fichier externe est une chose (et je suis d'accord avec toi que c'est plus complexe que la simple notion de gros ou petit-boutien). De plus tu peux examiner le fichier reçu pour te faire une idée pratique de ce que tu vas recevoir.
Mais quand il s'agit de programmer, tu dois prévoir tout ce qui va arriver à ton joli programme (c'est cela le sel). Et c'est là que la diversité des plateformes entre en ligne de compte.
OK, « ta machine » ci-dessus est trompeur, puisque si on écrit un programme non portable pour une seule machine il « suffit » de regarder dedans pour savoir comment cela se comporte; et si on écrit du vraiment portable, évidemment la machine cible est une machine virtuelle union de toutes celles que l'on peut potentiellement rencontrer, ce n'est pas « sa » machine à lui.
Une autre chose qui me vient maintenant à l'idée (après avoir lu le post de Gaby) et qui est peut-être ce que tu voulais dire, c'est que bien que le fichier soit « normalisé », il y a des chances non négligeables de recevoir des « versions » légèrement incompatibles entre elles, parce que créées par la méthode brutale (ma machine est gros boutien, la norme dit gros boutien, donc fwrite et basta); évidemment les subtiles variations de format, du genre ordre des mots,... Donc la routine de lecture doit être « à l'épreuve des balles », et ne pas sauter même sur des séquences a priori invalides (si on comprend la norme d'une certaine façon) mais parfaitement possibles avec certaines machines et les écritures brutales.
Antoine
Stephane Legras-Decussy
Charlie Gordon a écrit dans le message : co1gl2$86t$
Chqrlie (on a crusade against do/while loops ;-)
ce serait très interessant que tu fasses un p'tit topo sur le pourquoi du comment de cette croisade. :-)
Charlie Gordon <news@chqrlie.org> a écrit dans le message :
co1gl2$86t$1@reader1.imaginet.fr...
Chqrlie (on a crusade against do/while loops ;-)
ce serait très interessant que tu fasses un p'tit topo
sur le pourquoi du comment de cette croisade. :-)
Tu as raison ! Pour supprimer les bugs, supprimons les programmes !
James Kanze
Gabriel Dos Reis writes:
|> James Kanze writes:
|> Tu dois parler d'une pratique bien limitée.
En ce qui concerne les flottants, je l'avoue. Je m'es sers éventuellement quand je veux sortir des pourcents, c'est à peu près tout. (J'avais bien implémenté une bibliothèque standard de C, il y a longtemps, mais ça ne devait servir que sur deux architectures : Intel et NSC -- tous les deux petit-boutiens à tous les niveaux.)
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|> James Kanze <james.kanze@free.fr> writes:
|> Tu dois parler d'une pratique bien limitée.
En ce qui concerne les flottants, je l'avoue. Je m'es sers
éventuellement quand je veux sortir des pourcents, c'est à peu près
tout. (J'avais bien implémenté une bibliothèque standard de C, il y a
longtemps, mais ça ne devait servir que sur deux architectures : Intel
et NSC -- tous les deux petit-boutiens à tous les niveaux.)
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
En ce qui concerne les flottants, je l'avoue. Je m'es sers éventuellement quand je veux sortir des pourcents, c'est à peu près tout. (J'avais bien implémenté une bibliothèque standard de C, il y a longtemps, mais ça ne devait servir que sur deux architectures : Intel et NSC -- tous les deux petit-boutiens à tous les niveaux.)
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
