type and size of bit-fields

[Ed Taft]

Consider a C compiler that treats int as 16 bits and long int as 32 bits.
What should be the interpretation of the following bit-field appearing in a
struct?

  int foo: 24;

The ANSI C standard states: "A bit-field is interpreted as an integral type
consisting of the specified number of bits." Based on this, one might expect
foo to be treated as a 24-bit integer. That is, in this context, "int" means
"integral type", not "16-bit integer".

However, this interpretation may be contradicted by an earlier statement
that the width of a bit-field "shall not exceed the number of bits in an
ordinary object of compatible type." This statement is somewhat enigmatic,
since it depends on what you think is meant by "compatible type" in this
instance.

Alas, different compilers seem to disagree about this. Ed McCreight recently
made a survey of four C compilers for the IBM PC and reports the following
results:

* WATCOM 8.0 works as described above.

* MicroSoft 6.00A, Zortech 2.1, and Borland BCC 2.0 complain that the
  bit-field is too large to be an int.

In light of this, a possible work-around comes to mind:

  long int foo: 24;

Unfortunately, this violates the ANSI C standard, which states: "A bit-field
may have type int, unsigned int, or signed int" -- omitting long types.
Surveying the same four compilers, we observe the following:

* WATCOM 8.0 and Borland BCC 2.0 reject this declaration.

* Microsoft 6.00A and Zortech 2.1 accept it without complaint and
  (apparently) interpret the bit-field as intended.

We haven't yet discovered any way to get Borland BCC 2.0 to accept
bit-fields longer than 16 bits.

Now admittedly, nearly everything to do with bit-fields is implementation
dependent. On the other hand, it doesn't seem unreasonable to expect an
implementation to support bit-fields of any size up to and including the
largest integral type. Can anyone offer authoritative information on this
matter?


Ed Taft      taft at adobe.com      ...decwrl!adobe!taft