Bitfileds в Little-Endian и Big-Endian [duplicate]

Насколько я понимаю, битовые поля являются чисто конструкциями компилятора

И это часть проблемы. Если использование бит-полей было ограничено тем, что принадлежит компилятору, то как компилятор упаковывал биты или заказывал их, он почти никому не беспокоился.

Однако битовые поля, вероятно, используется гораздо чаще для моделирования конструкций, которые являются внешними по отношению к домену компилятора - аппаратным регистрам, протоколу «провод» для связи или макет формата файла. У этих вещей есть строгие требования о том, как биты должны быть выложены, а использование битовых полей для их моделирования означает, что вам приходится полагаться на определенные реализацией и, что еще хуже, неуказанное поведение того, как компилятор будет макетировать бит-поле .

Короче говоря, бит-поля не указаны достаточно хорошо, чтобы сделать их полезными для ситуаций, которые, по-видимому, наиболее часто используются.

ISO / IEC 9899: 6.7.2.1 / 10

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

Безопаснее использовать операции смены битов вместо того, чтобы делать какие-либо предположения о упорядочении или выравнивании битового поля при попытке написать переносимый код независимо от системы endianness или bitity.

Также см. EXP11-C. Не применяйте операторов, ожидающих одного типа, к данным несовместимого типа .

Чтобы отследить наиболее важные моменты: если вы используете это на одной платформе компилятора / HW в качестве программного обеспечения только для конструирования, то утверждение не будет проблемой. Если вы используете код или данные на нескольких платформах или должны соответствовать макетам аппаратного бита, тогда это IS проблема. И много профессионального программного обеспечения является кросс-платформенным, поэтому он должен заботиться.

Вот простейший пример: у меня есть код, который хранит числа в двоичном формате на диск. Если я не буду писать и читать эти данные на диск сам явно байтом по байту, то это будет не то же самое значение, если читать из противоположной системы endian.

Конкретный пример:

int16_t s = 4096; // подписанное 16-битное число ...

Предположим, что моя программа поставляется с некоторыми данными на диске, который я хочу прочитать. Скажем, я хочу загрузить его как 4096 в этом случае ...

fread ((void *) & amp; s, 2, fp); // читаю его с диска как двоичный ...

Здесь я прочитал его как 16-битное значение, а не как явные байты. Это означает, что если моя система соответствует контенту, хранящемуся на диске, я получаю 4096, а если это не так, я получаю 16 !!!!!

. Таким образом, наиболее частое использование endianness - номера, а затем выполните bswap, если вы не соответствуете. Раньше мы хранили данные на диске как большие, потому что Intel был странным человеком и предоставлял высокоскоростные инструкции для обмена байтами. В настоящее время Intel настолько распространена, что часто делает Little Endian по умолчанию и свопит, когда на большой системе endian.

Более медленный, но нейтральный подход, основанный на endian, состоит в том, чтобы делать ВСЕ I / O по байтам, то есть:

uint_8 ubyte; int_8 sbyte; int16_t s; // читаем s в нейтральном нейтральном направлении

// Давайте выберем маленький конец в качестве нашего выбранного порядка байтов:

fread ((void *) & amp; ubyte, 1, fp); // Только чтение 1 байт за время fread ((void *) & amp; sbyte, 1, fp); // Только чтение 1 байт за раз

// Реконструкция s

s = ubyte | (sByte & lt; 8);

Обратите внимание, что это идентично коду, который вы пишете, чтобы сделать подгон под конец, но вам больше не нужно проверять соответствие. И вы можете использовать макросы, чтобы сделать это менее болезненным.

Я использовал пример хранимых данных, используемых программой. Другое основное приложение - записать аппаратные регистры, где эти регистры имеют абсолютный порядок. Одно ОЧЕНЬ ОБЩЕЕ место, которое появляется, это графика. Избегайте верности, и ваши каналы красного и синего цвета меняются на противоположные! Опять же, проблема заключается в переносимости - вы можете просто адаптироваться к данной аппаратной платформе и графической карте, но если вы хотите, чтобы ваш одинаковый код работал на разных машинах, вы должны проверить.

Вот классический тест :

typedef union {uint_16 s; uint_8 b [2]; } EndianTest_t;

EndianTest_t test = 4096;

if (test.b [0] == 12) printf («Big Endian Detected! \n»);

Обратите внимание, что проблемы с битовыми полями существуют, но они ортогональны проблемам с контентом.