Bitfields & alignement

Bonjour,

Je rencontre des problèmes avec l'utilisation de bitfields. Sujet que je maîtrise mal.

J'avais la structure suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

// 2*32 bits partiellement remplis struct MaStruct { unsigned long var01 :10; unsigned long var02 : 3; unsigned long var03 : 5; unsigned long var04 : 5; unsigned long var05 : 3; unsigned long var06 : 3; unsigned long var07 : 1; unsigned long var08 : 1; // on saute 1bit // ------------------------- unsigned long var09 :17; unsigned long var10 : 8; // 7 derniers bits non utilisés };

---

que j'ai transformée en :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// 64 bits totalement remplis struct MaStruct { uint64_t var01 :10; uint64_t var02 : 3; uint64_t var03 : 5; uint64_t var04 : 5; uint64_t var05 : 3; uint64_t var06 : 3; uint64_t var07 : 1; uint64_t var08 : 1; uint64_t var09 :17; uint64_t var10 : 8; uint64_t var11 : 8; }};

---

• j'ai rajouté un champ (var11)
• j'ai changé le type de 32 en 64 bits
• le cumul des bits fait 64 au lieu de 56

La structure est initialement remplie par un reinterpret_cast faisant suite à une lecture de fichier.

Il semble qu'à la suite de ma modif, les données que je récupère à partir du 32ème bit de la structure ne soient pas bonnes : à partir du champ var09, il y a un décalage d'1 bit (var09 et var10 ont une valeur 2 fois trop grande).
Auriez-vous une idée ?

PS : j'utilise VS2010 en 64 bits

Lu,

Il y a une chose que je ne comprends pas dans la première partie: les commentaires "on saute 1 bit" et "7 derniers bits non utilisés". On le saute quand le bit Oo ?
J'ai l'impression qu'il manque un truc genre unsigned long:1; //ou 0.

@jo_link_noir
Non je pense qu'il faut le voir comme cela :mrgreen:
Au début on a 2 paquets de var01 à var08 (p1) et var09-var10 (p2)
Mais p1 ne représente que 31bits et p2 25bits.

C'est pour cela que

1. '"on saute 1bit" pour que p1 ait 32bits
2. "7 derniers bits non utilisés" pour que p2 ait 32bits

Mais justement oodini, a récupéré le bit "vacant" de p1 pour le mettre dans p2 (c'est var11: 7+1= 8) :mrgreen:

Ce fœtus est précoce et a déjà l'esprit bien affuté. :)

C'est effectivement comme ça que ça se passe (ou devrait se passer).
Sauf que, comme décrit, il y a un soucis...

Bonjour,

Compiles tu en 64 bits? car si tu compile en 32 bits, ta structure sera alignée en bloc de 32 bits ce qui pourrait expliquer le décalage d'un bit supplémentaire au 31ème bit.

Je compile en 64 bits. Hélas, c'est là qu'est l'os.

À mon avis, ce n’est pas un problème de compilation en 64 bits, mais de taille utilisée pour l’alignement.

Tu remplaces des long (32 bits --> alignement sur 32 bits --> 1 bit est réservé avant var09 pour qu’il ne se retrouve pas à cheval entre 2 longs) par des uint64_t (64 bits --> pas de problème, pas de bit réservé).

Si tu as vraiment besoin de uint64_t, tu peux, au choix :
- réserver le 1 bit pour faire l’alignement entre var08 et var09
- utiliser un uint32_t de longueur 0 avant var09 pour forcer l’alignement sur le prochain mot de 32 bits

Justement, en utilisant un uint64_t, je pensais ne pas avoir à me soucier de l'alignement sur 32 bits.
Je peux restreindre le champ que j'ai ajouté à 7 bits. Je vais faire ça, et revenir à des ulong.

J’ai l’impression que tu veux faire deux choses incompatibles entre elles :
- décaler la structure pour avoir 8 bits à la fin (d’où le passage à des uint64_t pour régler la problématique d’alignement)
- garder la compatibilité binaire, et donc var9 qui commence au deuxième mot

Y a pas de magie. Tu auras soit l’un, soit l’autre, mais pas les deux.

Oui, j'en étais également arrivé à cette conclusion peu flatteuse...

Cela dit, j'aurais bien voulu en discuter avec le gars qui me donne les données à manger. parce que ç doit vouloir dire qu'avec l'ancien système, il décalait délibérément les données d'1 bit (ce n'est pas écrit en C/C++).

Tu peux quand même résoudre le problème en dissociant la représentation mémoire de la sérialisation (à condition que tes 8 derniers bits ne soient là que pour toi et n’aient pas d’importance dans les données).

Ça va ralentir (un peu) la lecture, mais bon…

Ils ont de l'importance dans les données. :)

J'ai du mal à comprendre pourquoi simplement rajouter une variable de bourrage d'1 bit entre var08 et var09 ne marcherait pas.

Si tu ajoutes un bit de bourrage, tu arrives au total à 65 bits.

Ah oui, avec l'ajout de var11.
Et bien, la seule façon que je vois de rester compatible sans dépasser la taille est de couper var11 en deux (placer un de ses bits entre var08 et var09).