Convertir de little-endian à big-endian

[Arty]

Existe-t-il des fonctions "standards" pour passer de little-endian à big-endian? Je voudrais que mon code soit portable au maximum.

Je sais qu'il existe htonl, htons, ntohl, ntohs dans la librairie standard pour passer de l'ordonance des octets du réseau à celui de la machine, mais ils ne font rien sur un PowerPC puisque c'est un big-endian...

[Driden]

Je sais qu'il existe htonl, htons, ntohl, ntohs dans la librairie standard pour passer de l'ordonance des octets du réseau à celui de la machine, mais ils ne font rien sur un PowerPC puisque c'est un big-endian...
[right][snapback]803362[/snapback][/right]

Je comprends pas bien ou est ton problème si le codage n'a pas besoin d'etre modifié ?

[Arty]

Moi j'ai besoin de convertir de big-endian à little-endian (et l'inverse), ce que ne font pas les fonctions que j'ai cité! En fait j'en ai parlé au cas où quelqu'un me fasse remarquer leur existence, mais ce ne sont pas celles qu'il me faut!

[Driden]

Tu pourrais donner des détails sur l'applications, tu l'utilises via un reseau de machines d'architectures hétérogènes ?

[cbrandt]

question à tout hasard, serait-ce pour avoir des données numériques (entiers courts, longs...) dans un fichier qui serait compatible avec la version mac et windows de ton application ?

[Arty]

question à tout hasard, serait-ce pour avoir des données numériques (entiers courts, longs...) dans un fichier qui serait compatible avec la version mac et windows de ton application ?
[right][snapback]803435[/snapback][/right]

Oui! C'est ça.

[Driden]

question à tout hasard, serait-ce pour avoir des données numériques (entiers courts, longs...) dans un fichier qui serait compatible avec la version mac et windows de ton application ?
[right][snapback]803435[/snapback][/right]

Oui! C'est ça.
[right][snapback]803498[/snapback][/right]

T'as pas besoin de te préoccuper de ça normalement la machine bosse sur sa propre représentation des données.

[cbrandt]

T'as pas besoin de te préoccuper de ça normalement la machine bosse sur sa propre représentation des données.

SI ! Il FAUT s'en préoccuper, si on veut qu'un document de l'application soit identique dans les deux environnements.

Alors voilà la solution:
considère ton fichier comme le réseau. Donc dans les DEUX versions, mac et pc, utilise htonl et htons juste avant d'écrire un entier dans le fichier, et ntohl et ntohs juste après avoir lu un entier du fichier.
Sur un mac ça ne fera certes rien, mais sur un pc ça fera les conversions. Et ton source sera identique.
[EDIT]
Par contre, pour les nombres non-entiers, il se pourrait que les différences de codage ne soient pas uniquement liées au problème big-endian/little-endian. Pour ce cas là je n'ai pas de solution toute prête...
[/EDIT]

Ce message a été modifié par cbrandt - 8 Aug 2004, 23:13.

[Driden]

T'as pas besoin de te préoccuper de ça normalement la machine bosse sur sa propre représentation des données.

SI ! Il FAUT s'en préoccuper, si on veut qu'un document de l'application soit identique dans les deux environnements.

[right][snapback]803561[/snapback][/right]

On s'est pas compris je crois , je parlais des données internes au programme et non pas de données extraites d'un fichier. En effet dans ce cas il faut faire attention à la representation pour que ça reste compatible.

[dulrich]

je pige pas très bien, ce genre de différence n'est pas gérer directement dans les bibliothèques du langage lors de l'écriture dans un fichier (genre un fwrite)?

[Arty]

OK, merci pour l'idée de choisir une convention au départ qui me permette d'utiliser les fonctions htonl, etc...

je pige pas très bien, ce genre de différence n'est pas gérer directement dans les bibliothèques du langage lors de l'écriture dans un fichier (genre un fwrite)?
[right][snapback]803581[/snapback][/right]

Non, là on parle du codage dans les fichiers. Comme l'a dit Driden, pour toutes les données internes au programme on s'en fiche puisque tout est géré de manière transparente, mais dès que tu écris tes données dans un fichier que tu veux échanger avec un autre environnement, il a le risque qu'il ne soit pas lu de la même manière.

[dulrich]

ayant eu affaire à ce genre de chose (dump de la mémoire d'un prog dans un fichier) et n'ayant jamais pris en considération ce genre de problème, je ne comprends toujours pas.


Soit tu balance quelque chose dans un fichier, et tu veux que lors de la lecture de ce fichier il n'y ait pas de problème sur une autre architecture. Je connais les endians...
Mais la plupart des fonctions d'écritures dans un fichier n'ont-elles pas une convention justement? Histoire que le transfert sur une uatre plateforme fonctionne?

[SuperCed]

Je sais qu'il existe une fonction qui fait ça dans les socket BSD je crois. En fait, dans le cas d'un PowerPC, la fonction de fait rien, mais sur du Intel, ça fait la transformation.

Il faut toujours le faire quand tu utilises les sockets BSD et que tu veux un code portable.

Attends que je retrouve...

Je crois que c'est ça :

CODE

#include <netinet/in.h>

long htonl(u_long x);
short htons(u_short x);
u_long ntohl(u_long x);
u_short ntohs(u_short x);

En effet, les données transitant sur le net doivent être en big indian.

[Arty]

Je sais qu'il existe une fonction qui fait ça dans les socket BSD je crois. En fait, dans le cas d'un PowerPC, la fonction de fait rien, mais sur du Intel, ça fait la transformation.

Il faut toujours le faire quand tu utilises les sockets BSD et que tu veux un code portable.

Attends que je retrouve...

Je crois que c'est ça :

CODE

#include <netinet/in.h>long htonl(u_long x);short htons(u_short x);u_long ntohl(u_long x);u_short ntohs(u_short x);

En effet, les données transitant sur le net doivent être en big indian.
[right][snapback]803792[/snapback][/right]

Oui, oui, je sais, j'en ai parlé plus haut

[f_cam]

ayant eu affaire à ce genre de chose (dump de la mémoire d'un prog dans un fichier) et n'ayant jamais pris en considération ce genre de problème, je ne comprends toujours pas.


Soit tu balance quelque chose dans un fichier, et tu veux que lors de la lecture de ce fichier il n'y ait pas de problème sur une autre architecture. Je connais les endians...
Mais la plupart des fonctions d'écritures dans un fichier n'ont-elles pas une convention justement? Histoire que le transfert sur une uatre plateforme fonctionne?
[right][snapback]803665[/snapback][/right]

Pas à ma connaissance (en C du moins). Un truc comme fwrite il prends une série de octets à écrire et il le fait dans le même ordre que les octets sont stoqués en mémoire. Si tu lui donne 8 octets il n'a aucun moyen de savoir si c'est un entier ou float sur 8 octets, une chaine de charactères de 8 octets, un entier sur 4 octets et 2 autres sur 2 octets etc....
Pareil fread lit un flux d'octets, sans aucune connaissance de leur type.

[Bac's]

Je ne comprends toujours pas où tu veux en venir. Si tu veux que la représentation mémoire de tes données soit celle du processeur et que les fichiers créés par ton application soient indépendants de la plate-forme, la solution de cbrandt est la bonne.

Tu peux même avoir une représentation encore plus indépendante (qui tienne compte des différences de taille par exemple) en utilisant les fonctions XDR (eXternal Data Representation).

[f_cam]

Et si le format de fichier a été défini sur pc, par quelqu'un qui n'a pas pris le soin d'utiliser htonl et cie?

[Bac's]

Et si le format de fichier a été défini sur pc, par quelqu'un qui n'a pas pris le soin d'utiliser htonl et cie?
[right][snapback]804074[/snapback][/right]

Ben voilà, on y arrive !!

Si tu as un entier sur 16 bits, tu peux faire la manipe suivante :

CODE

unsigned short val;

read(fd, &val, sizeof(val));
val = val >> 8 | val << 8;

Pour du 32 bits, ce serait :

CODE

unsigned int val;

read(fd, &val, sizeof(val));
val = val >> 24  | (val & 0xFF0000) >> 8 | (val & 0xFF00) << 8 | val << 24;

Dans le deux cas, tu peux de fendre d'une fonction si tu veux quitte à la déclarer inline.

Ce message a été modifié par Bac's - 9 Aug 2004, 14:56.

[Arty]

Et si le format de fichier a été défini sur pc, par quelqu'un qui n'a pas pris le soin d'utiliser htonl et cie?
[right][snapback]804074[/snapback][/right]

Ben voilà, on y arrive !!

Si tu as un entier sur 16 bits, tu peux faire la manipe suivante :

CODE

unsigned short val;

read(fd, &val, sizeof(val));
val = val >> 8 | val << 8;

Pour du 32 bits, ce serait :

CODE

unsigned int val;

read(fd, &val, sizeof(val));
val = val >> 24  | (val & 0xFF0000) >> 8 | (val & 0xFF00) << 8 | val << 24;

Dans le deux cas, tu peux de fendre d'une fonction si tu veux quitte à la déclarer inline.
[right][snapback]804106[/snapback][/right]

On est d'accord, ca revient au même. Mais pour l'écriture dans un fichier, il faut bien choisir une convention au départ, d'où la bonne technique proposée par cbrandt.

[p3consulting]

Existe-t-il des fonctions "standards" pour passer de little-endian à big-endian? Je voudrais que mon code soit portable au maximum.

Je sais qu'il existe htonl, htons, ntohl, ntohs dans la librairie standard pour passer de l'ordonance des octets du réseau à celui de la machine, mais ils ne font rien sur un PowerPC puisque c'est un big-endian...
[right][snapback]803362[/snapback][/right]

Tout est dans ce header:
#include <architecture/byte_order.h>