C / C ++: Bitfeldreihenfolge und -ausrichtung erzwingen

Ich habe gelesen, dass die Reihenfolge der Bitfelder innerhalb einer Struktur plattformspezifisch ist. Was passiert, wenn ich verschiedene compilerspezifische Verpackungsoptionen verwende? Werden diese Garantiedaten in der richtigen Reihenfolge gespeichert, in der sie geschrieben wurden? Beispielsweise:

struct Message
{
  unsigned int version : 3;
  unsigned int type : 1;
  unsigned int id : 5;
  unsigned int data : 6;
} __attribute__ ((__packed__));

Auf einem Intel-Prozessor mit dem GCC-Compiler wurden die Felder wie gezeigt im Speicher angeordnet. Message.versionwar die ersten 3 Bits im Puffer und Message.typefolgte. Wenn ich für verschiedene Compiler äquivalente Strukturpackoptionen finde, ist dies plattformübergreifend?

Nein, es wird nicht vollständig tragbar sein. Packoptionen für Strukturen sind Erweiterungen und selbst nicht vollständig portierbar. Darüber hinaus heißt es in C99 §6.7.2.1, Absatz 10: "Die Reihenfolge der Zuordnung von Bitfeldern innerhalb einer Einheit (von hoher zu niedriger Ordnung oder von niedriger zu hoher Ordnung) ist implementierungsdefiniert."

Selbst ein einzelner Compiler kann das Bitfeld beispielsweise je nach Endianness der Zielplattform unterschiedlich anordnen.

Bitfelder variieren stark von Compiler zu Compiler, sorry.

Mit GCC legen Big-Endian-Maschinen zuerst das große Ende und die kleinen Endian-Maschinen zuerst das kleine Ende an.

K & R sagt: "Benachbarte [Bit-] Feldmitglieder von Strukturen werden in implementierungsabhängiger Richtung in implementierungsabhängige Speichereinheiten gepackt. Wenn ein Feld, das einem anderen Feld folgt, nicht passt ... kann es zwischen Einheiten aufgeteilt werden oder die Einheit kann es sein." gepolstert. Ein unbenanntes Feld mit der Breite 0 erzwingt diese Polsterung ... "

Wenn Sie ein maschinenunabhängiges Binärlayout benötigen, müssen Sie dies daher selbst tun.

Diese letzte Aussage gilt auch für Nicht-Bitfelder aufgrund des Auffüllens - jedoch scheinen alle Compiler eine Möglichkeit zu haben, das Byte-Packen einer Struktur zu erzwingen, wie Sie bereits für GCC entdeckt haben.

Bitfelder sollten vermieden werden - sie sind selbst für dieselbe Plattform nicht sehr portabel zwischen Compilern. aus der C99-Norm 6.7.2.1/10 - "Struktur- und Vereinigungsspezifizierer" (die C90-Norm enthält ähnliche Formulierungen):

Eine Implementierung kann jede adressierbare Speichereinheit zuweisen, die groß genug ist, um ein Bitfeld aufzunehmen. Wenn noch genügend Platz vorhanden ist, wird ein Bitfeld, das unmittelbar auf ein anderes Bitfeld in einer Struktur folgt, in benachbarte Bits derselben Einheit gepackt. Wenn nicht genügend Speicherplatz vorhanden ist, wird implementiert, ob ein nicht passendes Bitfeld in die nächste Einheit eingefügt wird oder benachbarte Einheiten überlappt. Die Reihenfolge der Zuordnung von Bitfeldern innerhalb einer Einheit (von hoher zu niedriger Ordnung oder von niedriger zu hoher Ordnung) ist implementierungsdefiniert. Die Ausrichtung der adressierbaren Speichereinheit ist nicht spezifiziert.

Sie können nicht garantieren, ob ein Bitfeld eine int-Grenze überspannt oder nicht, und Sie können nicht angeben, ob ein Bitfeld am unteren Ende des int oder am oberen Ende des int beginnt (dies ist unabhängig davon, ob der Prozessor dies ist Big-Endian oder Little-Endian).

Bevorzugen Sie Bitmasken. Verwenden Sie Inlines (oder sogar Makros), um die Bits zu setzen, zu löschen und zu testen.

Endianness spricht von Bytereihenfolgen, nicht von Bitreihenfolgen. Heutzutage ist es zu 99% sicher, dass Bitreihenfolgen festgelegt sind. Bei der Verwendung von Bitfeldern sollte jedoch die Endianness berücksichtigt werden. Siehe das folgende Beispiel.

#include <stdio.h>

typedef struct tagT{

    int a:4;
    int b:4;
    int c:8;
    int d:16;
}T;


int main()
{
    char data[]={0x12,0x34,0x56,0x78};
    T *t = (T*)data;
    printf("a =0x%x\n" ,t->a);
    printf("b =0x%x\n" ,t->b);
    printf("c =0x%x\n" ,t->c);
    printf("d =0x%x\n" ,t->d);

    return 0;
}

//- big endian :  mips24k-linux-gcc (GCC) 4.2.3 - big endian
a =0x1
b =0x2
c =0x34
d =0x5678
 1   2   3   4   5   6   7   8
\_/ \_/ \_____/ \_____________/
 a   b     c           d

// - little endian : gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
a =0x2
b =0x1
c =0x34
d =0x7856
 7   8   5   6   3   4   1   2
\_____________/ \_____/ \_/ \_/
       d           c     b   a

Wahrscheinlich die meiste Zeit, aber setzen Sie die Farm nicht darauf, denn wenn Sie sich irren, verlieren Sie viel.

Wenn Sie wirklich, wirklich identische Binärinformationen benötigen, müssen Sie Bitfelder mit Bitmasken erstellen - z. B. verwenden Sie einen vorzeichenlosen Kurzschluss (16 Bit) für die Nachricht und erstellen dann versionMask = 0xE000, um die drei obersten Bits darzustellen.

Es gibt ein ähnliches Problem bei der Ausrichtung innerhalb von Strukturen. Zum Beispiel sind Sparc-, PowerPC- und 680x0-CPUs alle Big-Endian-CPUs, und die übliche Standardeinstellung für Sparc- und PowerPC-Compiler besteht darin, Strukturelemente an 4-Byte-Grenzen auszurichten. Ein Compiler, den ich für 680x0 verwendet habe, ist jedoch nur an 2-Byte-Grenzen ausgerichtet - und es gab keine Option, die Ausrichtung zu ändern!

Bei einigen Strukturen sind die Größen bei Sparc und PowerPC identisch, bei 680 x 0 jedoch kleiner, und einige der Mitglieder befinden sich in unterschiedlichen Speicherversätzen innerhalb der Struktur.

Dies war ein Problem bei einem Projekt, an dem ich gearbeitet habe, da ein auf Sparc ausgeführter Serverprozess einen Client abfragte und herausfand, dass es sich um Big-Endian handelte, und davon ausging, dass er nur binäre Strukturen im Netzwerk herausspritzen und der Client damit umgehen konnte. Und das funktionierte gut auf PowerPC-Clients und stürzte auf 680x0-Clients stark ab. Ich habe den Code nicht geschrieben und es hat eine ganze Weile gedauert, bis ich das Problem gefunden habe. Aber es war einfach zu reparieren, sobald ich es tat.

Vielen Dank an @BenVoigt für Ihren sehr nützlichen Kommentar

Nein, sie wurden erstellt, um Speicherplatz zu sparen.

Linux Quelle tut ein bisschen Feld verwenden , um eine externe Struktur anzupassen: /usr/include/linux/ip.h hat diesen Code für das erste Byte einer IP - Datagramms

struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
        __u8    ihl:4,
                version:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
        __u8    version:4,
                ihl:4;
#else
#error  "Please fix <asm/byteorder.h>"
#endif

Jedoch in Anbetracht Ihres Kommentars Ich gebe es auf, das für den Multi-Byte - Bit - Feld , um Arbeit zu bekommen frag_off .

Die beste Antwort ist natürlich, eine Klasse zu verwenden, die Bitfelder als Stream liest / schreibt. Die Verwendung der C-Bit-Feldstruktur ist einfach nicht garantiert. Ganz zu schweigen davon, dass es als unprofessionell / faul / dumm angesehen wird, dies in der realen Codierung zu verwenden.