Gepackte Bitfelder in C-Strukturen – GCC

Ich arbeite mit Strukturen in c unter Linux. Ich habe angefangen, Bitfelder und das Attribut “packed” zu verwenden, und bin auf ein seltsames Verhalten gestoßen:

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

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

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

Wie kommt es, dass beide Strukturen – die genau gleich sind – eine unterschiedliche Anzahl von Bytes benötigen?

Ihre Strukturen sind nicht “genau gleich”. Ihr erstes hat drei aufeinanderfolgende Bitfelder, das zweite hat ein Bitfeld, ein (Nicht-Bitfeld) int und dann ein zweites Bitfeld.

Dies ist von Bedeutung: Aufeinanderfolgende Bitfelder (mit einer Breite ungleich Null) werden zu einem einzigen zusammengeführt Speicherortwährend ein Bit-Feld gefolgt von einem Nicht-Bit-Feld unterschiedliche Speicherstellen sind.

Ihre erste Struktur hat einen einzigen Speicherort, Ihre zweite hat drei. Sie können die Adresse des nehmen b member in Ihrer zweiten Struktur, nicht in Ihrer ersten. Zugriffe auf die b Mitglied rennt nicht mit Zugriffen auf die a oder c in Ihrer zweiten Struktur, aber sie tun es in Ihrer ersten.

Wenn man ein Nicht-Bit-Feld (oder ein Bit-Feld der Länge Null) hat, direkt nachdem ein Bit-Feld-Mitglied es gewissermaßen “schließt”, dann folgt ein anderer/unabhängiger Speicherort/ein anderes/unabhängiges Objekt. Der Compiler kann Ihre nicht “packen”. b Mitglied innerhalb des Bitfelds, wie es in der ersten Struktur der Fall ist.

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));

Das regelmäßige int b muss an einer Bytegrenze ausgerichtet werden. Es gibt also eine Polsterung davor. Wenn Sie setzen c gleich neben a diese Polsterung wird nicht mehr benötigt. Sie sollten dies wahrscheinlich tun, da der Zugriff auf nicht Byte-ausgerichtete Ganzzahlen wie int b:32 ist langsam.