Enforcing width of enum values within a struct in C99

Question

I have a structure that is intented to use 32 bits of storage:

struct foo_t {
    color_t color : 10
    some_type_t some_field : 22;
} 

, where color_t is an enum defined as

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

Note that color_t values currently fit in 8 bits, although in the future we might add more values (thus we reserved 10 bits for color)

In C99, I wonder if there is any guarantee that the width of color will be respected by the compiler. As discussed in this question, the compiler might choose to represent color_t as a char. At that point, the specified width appears incorrect according to the C99 spec:

The expression that specifies the width of a bit-field shall be an integer constant expression with a nonnegative value that does not exceed the width of an object of the type that would be specified were the colon and expression omitted.

How can I enforce that the color field uses 10 bits, then? Note that the problem goes away if the compiler used a regular integer to represent color_t, but this behavior cannot be assumed.

Answer 1

Add a final tag to your enum definition:

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

That has the added benefit of forcing the compiler / ABI to give your enum enough space for growth everywhere.

Of couse, that presupposes that your compiler allows enum's as bit-field types. It need not do so, though it has to diagnose it as a constraint-violation than:

6.7.2.1 Structure and union specifiers §5(constraints)

A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type. It is implementation-defined whether atomic types are permitted.

If you want to be strictly conforming, define the bit-field of type signed or unsigned, not of your special enum type. Still, that only guarantees 16 bits length possible.

Answer 2

Strictly speaking, C language (C99) only guarantees support for int, signed int, unsigned int and _Bool types in bit-field declarations, although specific implementations are explicitly allowed to support other types as implementation-dependent behavior.

In other words, in this case we are dealing with implementation-specific behavior, since you declared your bit-fields with enum types. The best approach would be to consult your compiler documentation, but I'd expect it to either honor your request for 10 bits or generate a diagnostic message if the chosen storage unit is not capable of accommodating 10 bits.

In my practice I usually use the following approach

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;
  ...
};

Note that this implementation does not attempt to reserve additional bits for the future expansion of the color type (do you really have a reason to do so?). Neither it attempts to automatically calculate the width of the bit-field. Instead, it simply catches the situation when the width is no longer sufficient, thus forcing the code maintainer to notice the problem and fix it manually.

P.S. An additional simple STATIC_ASSERT check can be added to make use that the bit-field width is not excessively large, if you care to have it "just right".

Answer 3

You could combine all that data in an fixed 32bit int (uint32_t), defined in stdint.h, and access values by bitwise operators.

Example:

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