uint8_t против беззнакового символа

Чтобы быть педантичным, некоторые системы могут не иметь 8-битного типа. Согласно Википедии:

Требуется реализация для определения целочисленных типов точной ширины для N = 8, 16, 32 или 64 тогда и только тогда, когда он имеет какой-либо тип, отвечающий требованиям. Нет необходимости определять их для любого другого N, даже если он поддерживает соответствующие типы.

Таким образом, существование uint8_t не гарантируется, хотя это будет для всех платформ, где 8 бит = 1 байт. Некоторые встроенные платформы могут отличаться, но это случается очень редко. Некоторые системы могут определять char типы как 16-битные, и в этом случае, вероятно, не будет никакого 8-битного типа.

Помимо этой (незначительной) проблемы, лучше всего подходит ответ @Mark Ransom мое мнение. Используйте тот, который наиболее четко показывает, для чего вы используете данные.

Кроме того, я предполагаю, что вы имели в виду uint8_t (стандартный typedef из C99, указанный в заголовке stdint.h), а не uint_8 (не являющийся частью какого-либо стандарта).

Все дело в написании кода, не зависящего от реализации. unsigned char не может быть 8-битным типом. uint8_t есть (при наличии).

Как вы сказали, «почти в каждой системе».

char, вероятно, изменится с меньшей вероятностью, но как только вы начнете использовать uint16_t и друзей, использование uint8_t смешивается лучше и может даже стать частью стандарта кодирования.

По моему опыту, есть два места, где мы хотим использовать uint8_t для обозначения 8 бит (и uint16_t и т. Д.) И где мы можем иметь поля меньше 8 бит. В обоих случаях пространство имеет значение, и нам часто нужно смотреть на необработанный дамп данных при отладке и иметь возможность быстро определить, что он представляет.

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

#pragma pack(1)
typedef struct {
  uint8_t    flag1:1;
  uint8_t    flag2:1;
  padding1   reserved:6;  /* not necessary but makes this struct more readable */
  uint32_t   sequence_no;
  uint8_t    data[8];
  uint32_t   crc32;
} s_mypacket __attribute__((packed));
#pragma pack()

Какой метод вы используете, зависит от вашего компилятора. Вам также может потребоваться поддержка нескольких разных компиляторов с одинаковыми файлами заголовков. Это происходит во встроенных системах, где устройства и серверы могут быть совершенно разными - например, у вас может быть устройство ARM, которое взаимодействует с сервером x86 Linux.

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

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

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

Вот несколько важных дискуссий:

работает пакет прагмы (1) и __attribute__ ((выровненный (1)))

Является ли __attribute __ ((упаковано)) / #pragma pack небезопасным для gcc?

http://solidsmoke.blogspot.ca/2010/07/woes-of-structure-packing-pragma-pack.html

Немногое. С точки зрения переносимости char не может быть меньше 8 бит, и ничто не может быть меньше char, поэтому, если данная реализация C имеет беззнаковый 8-битный целочисленный тип, это будет char. В качестве альтернативы, у него может не быть его вообще, и в этом случае любые typedef уловки станут неактуальными.

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

Это действительно важно, например, когда вы пишете сетевой анализатор. заголовки пакетов определяются спецификацией протокола, а не тем, как работает компилятор C.

Почти в каждой системе я встречал uint8_t == unsigned char, но это не гарантируется стандартом C. Если вы пытаетесь написать переносимый код и важно, какой именно размер памяти, используйте uint8_t. В противном случае используйте беззнаковый символ.