Kevin Kofler (./14) :
Kochise (./6) :
C'est pourquoi j'ai IMPERATIVEMENT besoin que la struct source corresponde bit-à-bit à celle de destination, d'où essayer de simuler le packing d'une plateforme 64 bits sur une plateforme 32 bits. Ou alors il reste la solution de 'packer' la structure avec #pragma pack(1) avant de la faire transiter, évitant les octets de padding, mais ça rend la structure inutilisable d'un point de vu run-time (désalignement des données, alignment fault).
Bah, les char pad[7] sont toujours efficaces…
Ouaip, sauf que j'utilise des
struct d'une librairie que c'est pas moi qui l'a faite. Donc j'aimerais autant que possible pouvoir utiliser la déclaration de la
struct sans avoir à la modifier (et donc recompiler la librairie, pour peu que j'ai le code source) mais pouvoir faire dialoguer mon driver avec des
struct de même taille de chaque coté de la liaison (le travail avec la lib se fait en
stdcall nativement suivant la plateforme, donc que la
struct soit plus ou moins grosse à cause des padding introduits par le compilo ne pose pas problème). Merci quand même pour ta proposition, j'y avais pensé en dernier recours...
Microsoft conseille l'usage de
#pragma pack(1) et de
__unaligned :
http://msdn.microsoft.com/en-us/library/ms253935.aspxSinon ils conseillent à :
http://msdn.microsoft.com/en-us/library/aa448596.aspx"In such cases, you can still use packed structures if you also carefully unpack members of a packed structure before using data in the program. This technique might involve copying the data in a structure member-by-member, or element-by-element, or field-by-field, into a temporary location that is correctly aligned."Justement ce que je veux éviter à tout pris !
Kochise