HDK Technical Reference

Bitfields

A bitfield is a way to save data space by packing several objects into a single storage unit. The syntax of field definition and access is based on structures:

   struct control {
   	unsigned int control_bits: 5;
   	unsigned int set_bits: 5;
   	unsigned int mod_bits: 3;
   }

Bitfields defined in consecutive order within the structure will, if possible, be packed within adjacent bits of the same integer. Individual fields are referenced just like any other structure members. Fields behave like small integers and may participate in arithmetic expressions just like other integers.

Different compilers use different bitfield conventions for structures, which is why it is often not possible to link files that were generated by different compilers into a single executable file. Code that does not use bitfields is generally easier to port across compilers, but using bitfields makes the code easier to read and maintain.

USL-based compilers allow the vendor to determine many of the bitfield behaviors. In general, the SCO OpenServer 5 compiler usually uses the behaviors that were defined for the Microsoft Compilers used for Open Desktop 3.0 and earlier releases, whereas the SVR5 compiler uses the behaviors that were defined for the SCO SVR5 1 and 2 compilers.

Some known differences in how the SCO OpenServer 5 and SVR5/SCO SVR5 2.0 compilers handle bitfields are:

bitfields that are not explicitly signed or unsigned

SCO OpenServer 5 compilers treat these as signed; SVR5 and SCO SVR5 1 and 2 compilers treat these as unsigned.

impact of #pragma pack on bitfields

On the SCO OpenServer 5 compilers, bitfield placement is affected; on SVR5 and SCO SVR5 1 and 2 compilers, #pragma pack is ignored for bitfields although it still applies to non-bitfield members in the same structure.

alignment of a bitfield after a non-bitfield

On SCO OpenServer 5 compilers, will always move to the next boundary that is appropriate for the type. For SVR5 and SCO SVR5 1 and 2 compilers, a bitfield may be placed near the end of a section of the structure that was appropriately aligned earlier. This typically results in tighter packing. For example:

   struct s1 { char c; int bf:24; };
   struct s2 { short s; int bf:24; };

On the SCO OpenServer 5 compiler, both s1 and s2 are 8 bytes long, and bf is offset 4 bytes from the beginning of the structure. For the SVR5 and SCO SVR5 1 and 2 compilers, s1 is 4 bytes and bf starts 1 byte from the beginning of the structure, but s2 is 8 bytes, and bf starts 2 bytes from the beginning of the structure.