Обеспечение ширины значений перечисления в структуре в C99

Добавьте последний тег к вашему определению enum:

typedef enum {
    //...
    DUMMY_FORCE_WIDTH = 0xffffffffu, // INT_MAX,
} color_t;

Это имеет дополнительное преимущество, заставляющее компилятор / ABI предоставлять вашему enum достаточно места для роста повсюду.

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

6.7.2.1 Спецификаторы структуры и объединения §5 (ограничения)

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

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

Строго говоря, язык C (C99) гарантирует поддержку только типов int, signed int, unsigned int и _Bool в объявлениях битовых полей, хотя конкретным реализациям явно разрешено поддерживать другие типы как зависящее от реализации поведение.

Другими словами, в этом случае мы имеем дело с поведением, зависящим от реализации, поскольку вы объявили свои битовые поля с типами enum. Лучшим подходом было бы обратиться к документации вашего компилятора, но я ожидаю, что он либо удовлетворит ваш запрос на 10 бит, либо сгенерирует диагностическое сообщение, если выбранная единица хранения не способна вместить 10 бит.

В своей практике я обычно использую следующий подход

typedef enum color_t {
  RED = 0,
  // other values...
  BLUE,
  COLOR_COUNT
} color_t;

#define COLOR_BIT_WIDTH 8u

STATIC_ASSERT(COLOR_COUNT <= (1 << COLOR_BIT_WIDTH));
// Use your favorite implementation of `STATIC_ASSERT`

struct foo_t {
  unsigned color : COLOR_BIT_WIDTH;
  ...
};

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

P.S. Можно добавить дополнительную простую проверку STATIC_ASSERT, чтобы убедиться, что ширина битового поля не слишком велика, если вы хотите, чтобы она была "правильной".

Вы можете объединить все эти данные в фиксированный 32-битный int (uint32_t), определенный в stdint.h, и получить доступ к значениям с помощью побитовых операторов.

Пример:

uint32_t data = (uint32_t)color<<22 | (uint32_t)some_field;
color=(color_t ) (data>>22);
some_field =(some_type_t ) (data & 0x3FFFFF);