type and size of bit-fields

Discussion in 'C Programming' started by john, Jun 19, 2010.

  1. john

    john Guest

    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?
     
    john, Jun 19, 2010
    #1
    1. Advertising

  2. john

    Eric Sosman Guest

    On 6/19/2010 5:02 PM, john wrote:
    > 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.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jun 19, 2010
    #2
    1. Advertising

  3. john

    Tim Rentsch Guest

    Eric Sosman <> writes:

    > On 6/19/2010 5:02 PM, john wrote:
    >> 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.
     
    Tim Rentsch, Jun 20, 2010
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xiaobin Yang

    size of class that uses bit fields

    Xiaobin Yang, Jun 7, 2004, in forum: C++
    Replies:
    3
    Views:
    332
    Xiaobin Yang
    Jun 7, 2004
  2. Replies:
    3
    Views:
    1,764
    Timothy Bendfelt
    Jan 19, 2007
  3. Replies:
    9
    Views:
    981
    Juha Nieminen
    Aug 22, 2007
  4. Mike -- Email Ignored

    Bit Order in Bit Fields

    Mike -- Email Ignored, May 2, 2009, in forum: C++
    Replies:
    0
    Views:
    384
    Mike -- Email Ignored
    May 2, 2009
  5. Jeff.M
    Replies:
    6
    Views:
    179
    Lasse Reichstein Nielsen
    May 4, 2009
Loading...

Share This Page