big and little endian!!

Version imprimable

30/05/2006, 15h20
moon93

big and little endian!!

pour eviter les problemes que peut évoqué une différence d'endianesse; j'ai trouvé dans une doc, qu'il faut utiliser l'opérateur << (shift) au lieu de cast pour l'opération de conversion!!!!!! mais j pas compris comment en utlisant un déclage peut changer le type!!!
30/05/2006, 15h22
Médinoc

C'est stupide. le cast d'une valeur marche parfaitement en toutes circonstances.

Par contre, le cast d'un pointeur est à proscrire.

l'xemple trouvé est:

Code:

1
2
3
4
 
int a;
char b[4];
a = *((int *)b);

eviter ça par:

Code:

1
2
3
4
 
int a;
unsigned char b[4];
a=(b[0]<<24)+(b[1]<<16)+(b[2]<<8)+b[3];

!!!

30/05/2006, 15h29
crocodilex

Une donnée en little endian ou en big endian n'a rien avoir avec le "type".
C'est juste une façon de ranger la donnée en mémoire qui est fonction de ton architecture.
Donc forcement cela ne se resoud pas à coup de "cast".
30/05/2006, 15h34
moon93

alors, quel genre de probleme peut engendrer la différence d'endianesse, si on essaye d'exécuter un programe ecrit sous une architecture big endian, dans une architecture little endian?
30/05/2006, 15h50
Trap D

C'est la lecture des nombres enregistrés qui pose problème, suppose 0x12345678 enregistré dans un type tu le liras 0x56781234 dans l'autre type ce qui change la valeur tu l'avoueras :(
30/05/2006, 16h02
crocodilex

Citation:

Envoyé par moon93

alors, quel genre de probleme peut engendrer la différence d'endianesse, si on essaye d'exécuter un programe ecrit sous une architecture big endian, dans une architecture little endian?

Ce n'est pas l'executable qui va poser problème, mais plutôt les données que tu manipules. Pour éviter ce genre de problème il faut absolument spécifier un format d'échange.
30/05/2006, 16h07
moon93

je comprend pas bien, parce que les données que je manipule seront introduites en temps réel apres avoir lancer l'exécutable!!!

stp, si tu peux m'explique d'avantage. merci
30/05/2006, 16h18
crocodilex

Citation:

Envoyé par moon93

je comprend pas bien, parce que les données que je manipule seront introduites en temps réel apres avoir lancer l'exécutable!!!

stp, si tu peux m'explique d'avantage. merci

Introduites par qui et comment ?
Si les données que tu manipules sont purement internes, alors dans ce cas il n'y a pas de problème.
Par contre si tu importes (ou exportes) les données par un moyen quelconque (fichier, réseau, etc..) dans ce cas il est important d'en connaître le format.
30/05/2006, 16h21
moon93

par exemple, les données peuvent etre récupérées d'une carte a puce,
30/05/2006, 16h30
Jack_serious

Citation:

Envoyé par moon93

par exemple, les données peuvent etre récupérées d'une carte a puce,

Dans ce cas il peut y avoir probleme...

Tant que les donnees restent internes, pas de probleme.

Le probleme de l'endianness vient du fait que selon les architectures ou les moyens de transport, les donnees ne sont pas stockees de la meme maniere.

Donc pour ta carte a puce, il faut que tu te renseigne sur la maniere dont les donnees sont encodees.
30/05/2006, 16h42
moon93

mon travail se situé a un niveau plus haut, c a d que les fonctions qui permet de lire ces cartes, ont était fournies, je récupère ces données et je les expoites!!!, donc si la différence d'endianesse est au niveau du lecteur de ces cartes, les API de ce lecteur me fournissent un format correcte de données! non?. et le fait que j tjr le meme OS ne résoud pas le probleme?

execuse moi, si mes questions sont nulles!
30/05/2006, 22h08
Emmanuel Delahaye

Citation:

Envoyé par moon93

mon travail se situé a un niveau plus haut, c a d que les fonctions qui permet de lire ces cartes, ont était fournies, je récupère ces données et je les expoites!!!, donc si la différence d'endianesse est au niveau du lecteur de ces cartes, les API de ce lecteur me fournissent un format correcte de données! non?. et le fait que j tjr le meme OS ne résoud pas le probleme?

Il faut lire la doc de l'API pour savoir quel est le format des données et si il est compatibles avec celui de l'architecture qui fait le traitement.
31/05/2006, 10h48
moon93

merci,

donc, je peux avoir deux données différentes, pour la lecture d'une meme carte sur deux lecteurs a base d'architectures différentes?
31/05/2006, 12h47
DaZumba

Citation:

Envoyé par moon93

donc, je peux avoir deux données différentes, pour la lecture d'une meme carte sur deux lecteurs a base d'architectures différentes?

La valeur sera la meme, mais la representation memoire (binaire, disons) peut etre differente. C'est assez simple: Si la carte envoie les donnees en big-endian et que la machine qui recoit les donnees est little-endian, alors il faut faire l'inversion des octets avant d'utiliser la variable. Si la machine est big-endian, alors il ne faut rien faire. Pour eviter ces complications, on choisit souvent d'emettre les donnees au format texte. Mais cela n'est pas toujours possible (pour des raisons de masse de donnees, par exemple). Dans ce cas, il faut prendre une convention (e.g. les reseaux travaillent en big-endian).
31/05/2006, 14h24
moon93

donc, je px avoir des problemes (faire deux fois une conversion!!) meme Si la carte envoie les donnees en little-endian et que la machine qui recoit les donnees est aussi little, vu que les reseaux travaillent en big-endian).:(
31/05/2006, 14h34
DaZumba

Citation:

Envoyé par moon93

donc, je px avoir des problemes (faire deux fois une conversion!!) meme Si la carte envoie les donnees en little-endian et que la machine qui recoit les donnees est aussi little, vu que les reseaux travaillent en big-endian).

Les reseaux travaillent en big-endian, certes, mais tu n'as pas a t'en pre-occupe. Je disais cela pour te donner une analogie avec ton probleme. Si tu sais que ta carte d'envoie du little-endian, alors tu fais la conversion si la machine est big-endian. Ce qui se passe entre la carte et la machine (i.e. transport reseau eventuel) est transparent et ne requiert pas d'action de ta part.
31/05/2006, 14h38
moon93

ok,je voie

merci ;)