Champs de bits emballés dans les structures c - GCC

Je suis en train de travailler avec les structures en c sous linux.
J'ai commencé à l'aide de champs de bits et les "paniers" de l'attribut et je suis tombé sur un comportement bizarre:

struct t1
{
    int a:12;
    int b:32;
    int c:4;
}__attribute__((packed));

struct t2
{
    int a:12;
    int b;
    int c:4;
}__attribute__((packed));

void main()
{
    printf("%d\n",sizeof(t1)); //output - 6
    printf("%d\n",sizeof(t2)); //output - 7
}

Comment les deux structures que sont exactement les mêmes - prendre diffrent nombre d'octets?

source d'informationauteur Shahar Sh

  1. 18

    Vos structures ne sont pas "exactement le même". Votre première a trois bits consécutifs-champs, le deuxième a un peu de champ, un (non bits) int, puis un deuxième bit-champ.

    Ceci est important: - consécutifs (non-largeur nulle) bit-champs sont fusionnées en une seule emplacement de mémoiretandis qu'un peu-terrain, suivi par un non-bits sont distincts des emplacements de mémoire.

    Votre première structure a un seul emplacement de mémoire, le second en a trois. Vous pouvez prendre l'adresse de la b membre de votre deuxième struct, pas dans votre premier. Accès à la b membre n'est pas la course avec accède à la a ou c dans votre deuxième structure, mais ils le font dans votre premier.

    Avoir un non-bits (ou de longueur zéro bits) juste après un peu de champ membre de la "ferme" dans un sens, ce suivi sera différent/indépendant de l'emplacement de la mémoire/de l'objet. Le compilateur ne peut pas "pack" de votre b membre à l'intérieur de la bit-champ comme il le fait dans la première struct.

  2. 13
    struct t1 //6 bytes
{
    int a:12; //0:11
    int b:32; //12:43
    int c:4;  //44:47
}__attribute__((packed));

struct t1 //7 bytes
{
    int a:12; //0:11
    int b;    //16:47
    int c:4;  //48:51
}__attribute__((packed));

    La régulière int b doit être alignée sur une frontière d'octet. Donc, il y a remplissage avant. Si vous mettez c juste à côté de a ce remplissage ne sera plus nécessaire. Vous devriez faire ceci, que l'accès aux non-aligné sur un octet entiers comme int b:32 est lente.