Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > type and size of bit-fields

Reply
Thread Tools

type and size of bit-fields

 
 
john
Guest
Posts: n/a
 
      06-19-2010
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?
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      06-19-2010
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
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      06-20-2010
Eric Sosman <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Preferred Size, Minimum Size, Size Jason Cavett Java 5 05-25-2008 08:32 AM
#define ALLOCIT(Type) ((Type*) malloc (sizeof (Type))) Yevgen Muntyan C Programming 10 02-13-2007 02:52 AM
mega pixels, file size, image size, and print size - Adobe Evangelists Frank ess Digital Photography 0 11-14-2006 05:08 PM
Re: Type casting- a larger type to a smaller type pete C Programming 4 04-02-2004 05:19 PM
Re: Type casting- a larger type to a smaller type heyo C Programming 3 04-01-2004 06:35 PM



Advertisments