type and size of bit-fields

[john]

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. I
made a survey of four C compilers for the IBM PC that I have to hand and
found 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?

 

[Eric Sosman]

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".

The wording in the current Standard (ISO/IEC 9899:TC3) is slightly
different: Instead of "an integral type" it reads "a signed or unsigned
integer type."

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.

Again, the current Standard's wording is different: "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." The newer wording removes any ambiguity that may
surround the older "compatible type."

Alas, different compilers seem to disagree about this. I
made a survey of four C compilers for the IBM PC that I have to hand and
found 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:

The current Standard adds _Bool to the list, plus "some other
implementation-defined type." That means that every compiler is
required to accept _Bool, int, signed int, and unsigned int (and
qualified versions thereof), and may accept additional types but is
not required to.

* 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?

Compilers may support, but are not required to support, bit-fields
wider than int. You're seeing compilers whose attitudes toward "may"
are different.

 

[Tim Rentsch]

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;

[snip]

Compilers may support, but are not required to support, bit-fields
wider than int. You're seeing compilers whose attitudes toward "may"
are different.

Compilers may support bitfields for /types/ wider than int. If
the bitfield's type is 'int', they may not allow bitfields wider than
'int' without issuing a diagnostic, because it's a constraint
violation. The width of a bitfield must be no larger than the
width of the non-bitfield-type used to declare it.