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 говорится: «Порядок распределения битовых полей в блоке (от высокого к низкому или от низкого к высокому) определяется реализацией».

Даже один компилятор может размещать битовое поле по-разному, например, в зависимости от порядка байтов целевой платформы.

Битовые поля сильно различаются от компилятора к компилятору, извините.

С GCC машины с прямым порядком байтов сначала выкладывают биты с обратным порядком байтов, а машины с обратным порядком байтов сначала размещают биты с обратным порядком.

K&R говорит: «Соседние элементы [битового] ​​поля структур упакованы в зависящие от реализации блоки памяти в направлении, зависящем от реализации. Когда поле, следующее за другим полем, не подходит ... оно может быть разделено между блоками или блок может быть padded. Безымянное поле шириной 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 бит) для сообщения, а затем сделайте такие вещи, как versionMask = 0xE000, чтобы представить три самых верхних бита.

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

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

Это была проблема с одним проектом, над которым я работал, потому что серверный процесс, запущенный на Sparc, запрашивал у клиента и обнаруживал, что он был прямым порядком байтов, и предполагал, что он может просто выдавать двоичные структуры в сеть, и клиент может справиться. И это прекрасно работало на клиентах 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 просто не гарантируется. Не говоря уже о том, что использование этого в реальном кодировании считается непрофессиональным / ленивым / глупым.