Comportement inattendu utilisant des champs de bits et des unions

Il y a plusieurs points de finesse lorsque l'on travaille avec struct et union . Le plus courant est que les champs sont généreusement remplis pour être alignés sur la taille des mots du processeur.

#pragma pack(1)   // this particular syntax is valid for many compilers

struct {
     char  c11;
     char  c12;
} s2;

#pragma pack(4)

semble que cela devrait être une structure à deux octets, mais étonnamment souvent sizeof (s1) ne sera pas 2, mais 4 - ou même 8. C'était le cas même dans les années 1980 avec des machines 16 bits.

C'est parce que les compilateurs C et C ++ aligneront chaque caractère élément d'une structure à une limite de deux ou quatre octets. Je n'ai pas encore vu les éléments de structure alignés sur une limite de 8 octets, mais nous n'avons pas encore d'architecture 64 bits si nécessaire.

La solution est d'invoquer une option de compilation pour "pack structures". Cela peut être fait sur la ligne de commande du compilateur ou en incluant une option #pragma appropriée avant la déclaration de structure:

struct {
     char   c1;
     char   c2;
} s1;

Tiré de la norme (n4835):

11.4.9 Champs de bits [class.bit]
1 [...] L'allocation de champs de bits dans un objet de classe est définie par l'implémentation. L'alignement des champs de bits est défini par l'implémentation. Les champs de bits sont regroupés dans une unité d'allocation adressable. [Remarque: les champs de bits chevauchent les unités d'allocation sur certaines machines et pas sur d'autres. Les champs de bits sont attribués de droite à gauche sur certaines machines, de gauche à droite sur d'autres. —End note]

Comme vous le voyez, la taille et l'alignement sont définis par l'implémentation. Vous pouvez donc obtenir le comportement attendu sur d'autres compilateurs / plates-formes, mais sur votre compilateur / plate-forme, vous obtenez des résultats différents de ceux que vous attendez.

D'après les spécifications que nous avons

Une implémentation peut allouer n'importe quelle unité de stockage adressable suffisamment grande pour contenir un bit- domaine. S'il reste suffisamment d'espace, un champ de bits qui suit immédiatement un autre champ de bits dans un la structure doit être emballée dans des bits adjacents de la même unité. S'il reste un espace insuffisant, si un champ de bits qui ne rentre pas est placé dans l'unité suivante ou chevauche des unités adjacentes est défini par la mise en œuvre. L'ordre d'attribution des champs de bits au sein d'une unité (d'ordre supérieur à d'ordre inférieur ou d'ordre inférieur à d'ordre élevé) est défini par l'implémentation. L'alignement du l'unité de stockage adressable n'est pas spécifiée.

Le comportement réel dépend donc de l'unité d'allocation de taille choisie par le compilateur pour les champs de bits, et s'il permet aux champs de s'étendre sur plusieurs unités d'allocation. Ce choix est défini par l'implémentation, mais une implémentation courante consiste à utiliser le type déclaré du champ de bits comme unité d'allocation, et à ne pas autoriser le franchissement des limites d'unité d'allocation. Ainsi, lorsque vous utilisez (unisgned) char, il utilise une unité d'allocation de 8 bits. Cela signifie qu'aucun des deux champs de bits ne peut être combiné en un seul octet (7 + 7> 8 et 7 + 2> 8), il finit donc par prendre 3 unités d'allocation (octets), qui arrondissent ensuite à 4 pour l'alignement lorsque combiné avec un court dans l'union.

Lorsque vous modifiez la taille du champ de bits à 6, les deuxième et troisième champs de bits peuvent désormais tenir dans un octet (6 + 2 = 8), donc cela ne prend que deux unités d'allocation.

Lorsque vous modifiez le type de champ de bits en short , il utilise une unité d'allocation de 16 bits, de sorte que les 3 champs de bits peuvent tenir dans une unité d'allocation.