taft@adobe.com (Ed Taft) (03/17/91)
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@adobe.com ...decwrl!adobe!taft
diamond@jit345.swstokyo.dec.com (Norman Diamond) (03/18/91)
In article <1991Mar18.004505.2293@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes: >In article <12638@adobe.UUCP> taft@adobe.COM writes: > >>What should be the interpretation of the following bit-field appearing in a >>struct? >> int foo: 24; >>... >>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. > >According to the Dec. 1988 draft, >>may have type int, unsigned int, or signed int" -- omitting long types. >was really: >SHALL have .... > >If this was changed in the final version, then we get to play more games >with the semantics of English. If it was not changed, then quite clearly >you cannot declare any bitfield longer than an int (in a conforming program), >besides being limited to the size of the type-specifiers if you specified any. >-- >Norman Diamond diamond@tkov50.enet.dec.com >If this were the company's opinion, I wouldn't be allowed to post it. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.