C / C ++: Примусовий порядок і вирівнювання бітового поля

Я читав, що порядок бітових полів у структурі залежить від платформи. Що щодо того, якщо я використовую різні варіанти упаковки для конкретного компілятора, чи зберігатимуться ці гарантійні дані у належному порядку, як вони написані? Наприклад:

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

На процесорі Intel із компілятором GCC поля були закладені в пам'ять так, як вони показані. Message.versionбуло першими 3 бітами в буфері, а Message.typeпотім. Якщо я знайду еквівалентні варіанти упаковки структур для різних компіляторів, чи буде це крос-платформним?

Ні, це не буде повністю портативним. Варіанти упаковки конструкцій є розширеннями і самі по собі не є повністю портативними. На додаток до цього, параграф 10 C99 §6.7.2.1, пункт 10 говорить: "Порядок розподілу бітових полів всередині одиниці (високого до нижчого або низького до високого порядку) визначається реалізацією".

Навіть один компілятор може розкласти поле бітів по-різному, наприклад, залежно від спрямованості цільової платформи.

Бітові поля сильно варіюються від компілятора до компілятора, вибачте.

За допомогою GCC машини великого ендіана спочатку викладають біти з великим кінцем, а маленькі машини ендіана спочатку викладають біти з малим кінцем.

K&R каже: "Сусідні [бітові] члени полів структур упаковуються в блоки, що залежать від реалізації, у напрямку, що залежить від реалізації. Коли поле, яке слідує за іншим полем, не поміщається ... воно може бути розділене між блоками або блок може бути заповнене. Безіменне поле шириною 0 змушує це заповнення ... "

Отже, якщо вам потрібна двійкова верстка, незалежна від машини, ви повинні зробити це самі.

Це останнє твердження також стосується небітових полів через заповнення - проте всі компілятори, мабуть, мають певний спосіб примусового пакетування байтів структури, як я бачу, ви вже виявили для GCC.

Слід уникати бітових полів - вони не дуже портативні між компіляторами навіть для тієї самої платформи. зі стандарту C99 6.7.2.1/10 - "Структура та специфікатори об'єднань" (подібне формулювання є у стандарті C90):

Реалізація може виділити будь-який адресований блок зберігання, достатньо великий, щоб вмістити бітове поле. Якщо залишається достатньо місця, бітове поле, яке безпосередньо слідує за іншим бітовим полем у структурі, має бути упаковано в сусідні біти того самого блоку. Якщо залишається недостатньо місця, чи вводиться бітове поле, яке не підходить, до наступного блоку чи перекриває сусідні блоки, визначається реалізацією. Порядок розподілу бітових полів всередині одиниці (високого до низького чи низького до високого) визначається реалізацією. Вирівнювання адресного блоку зберігання даних не вказано.

Ви не можете гарантувати, чи буде бітове поле `` охоплювати '' межу int чи ні, і ви не можете вказати, починається бітове поле з нижнього кінця int або верхнього кінця int (це не залежить від того, чи є процесор біг-ендіан або мало-ендіан).

Віддайте перевагу бітовим маскам. Використовуйте вбудовані рядки (або навіть макроси) для встановлення, очищення та тестування бітів.

endianness говорять про байтові замовлення, а не про бітові замовлення. На сьогоднішній день на 99% впевнені, що замовлення бітів є фіксованими. Однак при використанні бітових полів слід враховувати ендіанс. Дивіться приклад нижче.

#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

Найчастіше, напевно, але не робіть ставку на ферму, бо якщо ви помиляєтесь, ви програєте великі.

Якщо вам дійсно, дійсно потрібно мати однакову двійкову інформацію, вам потрібно буде створити бітові поля з бітовими масками - наприклад, ви використовуєте непідписаний шорт (16 біт) для Message, а потім зробите такі речі, як versionMask = 0xE000, щоб представити три найвищі біти.

Існує подібна проблема з вирівнюванням у структурах. Наприклад, процесори Sparc, PowerPC та 680x0 є великими, і загальним типовим для компіляторів Sparc та PowerPC є вирівнювання членів структури на 4-байтових межах. Однак один компілятор, який я використовував для 680x0, вирівнювався лише за двобайтовими межами - і не було можливості змінити вирівнювання!

Отже, для деяких структур розміри на Sparc та PowerPC однакові, але менші на 680x0, а деякі члени знаходяться в різних зміщеннях пам'яті в структурі.

Це була проблема з одним проектом, над яким я працював, оскільки серверний процес, що працює на Sparc, запитав би клієнта і виявив, що він є big-endian, і припустив, що він може просто розбризкувати двійкові структури в мережі, і клієнт міг би впоратися. І це добре працювало на клієнтах PowerPC, і в більшій мірі зазнало збою на клієнтах 680x0. Я не написав код, і знадобилося досить багато часу, щоб знайти проблему. Але це було легко виправити, коли я це зробив.

Дякую @BenVoigt за ваш дуже корисний коментар

Ні, вони створені для економії пам’яті.

Джерело Linux робить використання бітового поля для узгодження з зовнішньою структурою: /usr/include/linux/ip.h має цей код для першого байта в дейтаграммах 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

Однак у світлі Вашого коментаря я відмовляюся від спроб змусити це працювати для багатобайтового бітового поля frag_off .

Звичайно, найкраща відповідь - використовувати клас, який читає / записує бітові поля як потік. Використання структури бітового поля C просто не гарантоване. Не кажучи вже про те, що вважається непрофесійним / ледачим / дурним використовувати це в реальному кодуванні.