Discussion :

[esteban]

bonjour,

j'ai un probl�me qui me sid�re compl�tement... J'ai un struct compos� un peu dans ce genre :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
typedef monstruct1*{
   u_int8_t val1;
   u_int8_t val2;
} monstruct1_t;
 
typedef monstruct2*{
   u_int8_t val1;
   u_int32_t val2;
} monstruct2_t;

Lorsque je fais :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
monstruct1.val1 = 0xAA;
monstruct1.val2 = 0xFF;

La m�moire contient bien : AA FF

en revanche si je fais :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
monstruct2.val1 = 0xAA;
monstruct2.val2 = 0xFFFFFFFF;

La m�moire contient : AA 00 00 00 FF FF FF FF... d'o� j'en tire que j'ai 3 fois 0x00 qui se sont ins�r�s entre mon val1 et mon val2.
Si je mets val2 en u_int16_t j'obtiens : AA 00 FF FF... je n'ia plus qu'un 0x00 qui s'est ins�r�.

Je pr�cise que je suis sous g++ sous Mac os x en 64 bits. Est-ce que quelqu'un comprend quelque chose � tout ca ??? Je suis compl�tement incapable de construire un pauvre struct m�me pas compliqu� � cause de ca !!!

Merci pour votre aide
Tristan

[Astraya]

probablement du padding!
J'avais lanc� un thread la dessus ici
Arrange ta structure dans ce sens la et observe si il y a une diff�rence:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
typedef monstruct2*{
   u_int32_t val2;
   u_int8_t val1;
   u_int8_t val3;
   u_int8_t val4;
   u_int8_t val5;


} monstruct2_t;

[esteban]

Ah ouais on dirait que tu as raison, lorsque je mets mets valeurs dans l'ordre d�croissant il ne semble plus y avoir de probl�me. Par contre ce qui me g�ne c'est que je construis un paquet gr�ce � une succession de struct... je vais �tre oblig� de faire des contorsions avec mes paquets si je ne peux pas simplement mapper mes struct et mon paquet.

Y a-t-il une autre solution ?

[esteban]

Encore que je remarque une chose tout de m�me, mon struct est cens� faire 33 octets et un sizeof m'en donne 36 (chandelles...).

Son prototype est celui-ci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
 
        u_int32_t val1;
	u_int32_t val2;
	u_int32_t val3;
	u_int16_t val4;
	u_int8_t val5;
	u_int8_t val6;
	u_int8_t val7;
	u_int8_t val8[16];

[esteban]

Et pour le coup, les 3 octets surnum�raires sont plac�s � la fin de la struct...

[Obsidian]

Comme l'a dit Astraya, c'est une question de padding, dont la raison d'�tre est � l'alignement m�moire � des informations.

Je ne connais pas encore l'architecture 64 bits en d�tails, mais sur les 32 bits au moins, si ta m�moire et le bus qui la d�sert sont larges de 32 bits, alors chaque mot m�moire fait 32 bits. MAIS, l'unit� d'adressage de ton processeur, elle, est rest� sur huit bits, de sorte que chaque adresse m�moire r�f�rence un octet.

�a signifie que si tu veux lire un mot de 32 bits localis� � une adresse multiple de 4, il sera lu en une seule fois, mais que, par contre, si tu veux lire le m�me mot � une adresse non-multiple de 4, le micro-processeur va �tre oblig� d'aller lire de fa�on transparente deux demi-mots, donc faire deux transactions bus au lieu d'une, et d'aller extraire dans chacun la partie int�ressante, puis de recoller les morceaux pour reconstituer la donn�e qui t'int�resse.

Par cons�quent, si tu n'es pas limit� en m�moire, le compilateur va t�cher autant que faire se peut, de calculer des offsets multiples de 4 pour chacun des membres de ta structure s'ils d�passent huit bits, �tant entendu que les instances de ta structure, comme les autres variables, seront align�es de la m�me fa�on. Pour les instances d'un octet, il faut de toutes fa�ons l'extraire du mot lu, donc sa position importe peu.

Tu peux utiliser � #pragma pack � pour tenter de tasser tes membres dans tes structures si c'est n�cessaire, mais ce n'est absolument pas portable ni standard. Donc, le mieux est encore de concevoir des programmes qui ne soient pas sensibles � ce probl�me.

[3DArchi]

Par contre ce qui me g�ne c'est que je construis un paquet gr�ce � une succession de struct...

Tr�s mauvaise id�e :
1/ les probl�me d'alignement commencent � te sauter � la figure et se poseront � chaque plateforme cible/option de compilation ;
2/ une fois que tu en auras termin� avec les probl�mes d'alignement.... tu vas d�couvrir les probl�mes d'endianess ;
3/ ensuite tu te trouveras sur des plateformes exotiques o� tes acrobaties pour maitriser les alignements (pragma pack et autres) finiront par provoquer des adressages interdits.

Bref pour construire un paquet vu comme une suite d'octet, construit le en consid�rant l'octet et pas en essayant de mapper une structure sur une zone m�moire.

[esteban]

Ok j'ai r�ussi � r�soudre (temporairement) le probl�me en utilisant le pragma pack. Mais je vais suivre vos conseils car je travaille sur une application industrialis�e... le but est donc que ca fonctionne...
je vais utiliser des struct comme conteneur et ensuite je vais positionner mes valeurs dans un tableau de char pour construire le paquet � la main...

Merci pour vos conseils.

[Obsidian]

Ok j'ai r�ussi � r�soudre (temporairement) le probl�me en utilisant le pragma pack. Mais je vais suivre vos conseils car je travaille sur une application industrialis�e... le but est donc que ca fonctionne.. je vais utiliser des struct comme conteneur et ensuite je vais positionner mes valeurs dans un tableau de char pour construire le paquet � la main...

Si tu dois s�rialiser tes structures. N'utilises pas un tableau de char, car l'existence de ce type est garanti par la norme, mais pas son format. A contrario, les tailles des types d�finis dans <stdint.h> sont fix�es, mais ces types peuvent ne pas �tre disponibles si la plate-forme cible ne sait pas les g�rer.

Si c'est toi qui d�finit le protocole de communication, que tu n'es pas trop limit� en espace m�moire, et que la vitesse n'est pas un probl�me (soit parce que ta connexion est rapide, soit parce que la quantit� de donn�es � �mettre est r�duite), le plus simple est de les envoyer au format texte et de les reconvertir � la r�ception.