C / C ++: Force Bit Field Order and Alignment

Ho letto che l'ordine dei campi di bit all'interno di una struttura è specifico della piattaforma. E se utilizzo diverse opzioni di imballaggio specifiche del compilatore, i dati di garanzia verranno archiviati nell'ordine corretto così come vengono scritti? Per esempio:

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

Su un processore Intel con il compilatore GCC, i campi sono stati disposti in memoria così come vengono visualizzati. Message.versionerano i primi 3 bit nel buffer e Message.typeseguiti. Se trovo opzioni di impacchettamento della struttura equivalenti per vari compilatori, sarà multipiattaforma?

No, non sarà completamente portatile. Le opzioni di impacchettamento per le strutture sono estensioni e esse stesse non sono completamente portabili. In aggiunta a ciò, C99 §6.7.2.1, paragrafo 10 dice: "L'ordine di allocazione dei campi di bit all'interno di un'unità (da alto a basso o da basso a alto) è definito dall'implementazione".

Anche un singolo compilatore potrebbe disporre il campo di bit in modo diverso a seconda dell'endianness della piattaforma di destinazione, ad esempio.

I campi di bit variano ampiamente da compilatore a compilatore, mi dispiace.

Con GCC, le macchine big endian dispongono prima i bit big end e le macchine little endian dispongono prima i bit small end.

K&R afferma: "I membri adiacenti dei campi [bit-] delle strutture sono imballati in unità di memorizzazione dipendenti dall'implementazione in una direzione dipendente dall'implementazione. Quando un campo che segue un altro campo non si adatta ... potrebbe essere diviso tra imbottito. Un campo senza nome di larghezza 0 forza questo riempimento ... "

Pertanto, se hai bisogno di un layout binario indipendente dalla macchina, devi farlo da solo.

Quest'ultima affermazione si applica anche ai campi non bit a causa del riempimento, tuttavia tutti i compilatori sembrano avere un modo per forzare il confezionamento di byte di una struttura, come vedo che hai già scoperto per GCC.

I bitfield dovrebbero essere evitati: non sono molto portabili tra i compilatori anche per la stessa piattaforma. dallo standard C99 6.7.2.1/10 - "Specificatori di struttura e unione" (c'è una formulazione simile nello standard C90):

Un'implementazione può allocare qualsiasi unità di memoria indirizzabile abbastanza grande da contenere un campo di bit. Se rimane abbastanza spazio, un campo di bit che segue immediatamente un altro campo di bit in una struttura deve essere impacchettato in bit adiacenti della stessa unità. Se rimane spazio insufficiente, l'implementazione definisce se un campo di bit che non si adatta viene inserito nell'unità successiva o si sovrappone a unità adiacenti. L'ordine di allocazione dei campi di bit all'interno di un'unità (da ordine alto a ordine basso o da ordine basso a ordine alto) è definito dall'implementazione. L'allineamento dell'unità di memoria indirizzabile non è specificato.

Non puoi garantire se un campo di bit 'estenderà' o meno un limite int e non puoi specificare se un campo di bit inizia all'estremità inferiore di int o all'estremità alta di int (questo èindipendente dal fatto che il processore sia big-endian o little-endian).

Preferisci maschere di bit. Usa inline (o anche macro) per impostare, cancellare e testare i bit.

endianness parla di ordini di byte, non di ordini di bit. Al giorno d'oggi , è sicuro al 99% che gli ordini di bit siano corretti. Tuttavia, quando si usano i bitfield, è necessario tenere conto dell'endianness. Vedi l'esempio sotto.

#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

La maggior parte delle volte, probabilmente, ma non scommetterci sopra, perché se sbagli, perderai alla grande.

Se hai davvero, davvero bisogno di avere informazioni binarie identiche, dovrai creare campi di bit con maschere di bit, ad esempio usi un corto senza segno (16 bit) per Message, e poi fai cose come versionMask = 0xE000 per rappresentare i tre bit più in alto.

C'è un problema simile con l'allineamento all'interno degli struct. Ad esempio, le CPU Sparc, PowerPC e 680x0 sono tutte big-endian e l'impostazione predefinita comune per i compilatori Sparc e PowerPC è allineare i membri della struttura su limiti di 4 byte. Tuttavia, un compilatore che ho usato per 680x0 era allineato solo su limiti di 2 byte e non c'era alcuna opzione per modificare l'allineamento!

Quindi per alcune strutture, le dimensioni su Sparc e PowerPC sono identiche, ma più piccole su 680x0, e alcuni membri si trovano in offset di memoria diversi all'interno della struttura.

Questo era un problema con un progetto su cui ho lavorato, perché un processo server in esecuzione su Sparc avrebbe interrogato un client e avrebbe scoperto che era big-endian, e presumendo che potesse semplicemente spruzzare strutture binarie sulla rete e il client poteva farcela. E questo ha funzionato bene sui client PowerPC e si è arrestato in modo anomalo sui client 680x0. Non ho scritto il codice e ci è voluto un po 'di tempo per trovare il problema. Ma è stato facile risolverlo una volta che l'ho fatto.

Grazie @BenVoigt per il tuo utilissimo commento iniziale

No, sono stati creati per risparmiare memoria.

Source Linux fa utilizzare un campo di bit per abbinare ad una struttura esterna: /usr/include/linux/ip.h ha questo codice per il primo byte di un datagramma IP

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

Tuttavia alla luce del tuo commento sto rinunciando a provare a farlo funzionare per il campo bit multibyte frag_off .

Ovviamente la risposta migliore è usare una classe che legge / scrive campi di bit come flusso. L'uso della struttura del campo del bit C non è garantito. Per non parlare del fatto che è considerato poco professionale / pigro / stupido usarlo nella codifica del mondo reale.