0

I was reading this link

http://dec.bournemouth.ac.uk/staff/awatson/micro/articles/9907feat2.htm

I could not understand this following statements from the link, Please help me understand about this.

The programmer just writes some macros that shift or mask the appropriate bits to get what is desired. However, if the data involves longer binary encoded records, the C API runs into a problem. I have, over the years, seen many lengthy, complex binary records described with the short or long integer bit-field definition facilities. C limits these bit fields to subfields of integer-defined variables, which implies two limitations: first of all, that bit fields may be no wider, in bits, than the underlying variable; and secondly, that no bit field should overlap the underlying variable boundaries. Complex records are usually composed of several contiguous long integers populated with bit-subfield definitions.

ANSI-compliant compilers are free to impose these size and alignment restrictions and to specify, in an implementation-dependent but predictable way, how bit fields are packed into the underlying machine word structure. Structure memory alignment often isn’t portable, but bit field memory is even less so.

What i have understood from these statements is that the macros can be used to mask the bits to left or right shift. But i had this doubt in my mind why do they use macros? - I thought by defining it in macros the portability can be established irrespective of 16-bit or 32-bit OS..Is it true?I could not understand the two disadvantages mentioned in the above statement.1.bit fields may be no wider 2.no bit field should overlap the underlying variable boundaries

and the line,

Complex records are usually composed of several contiguous long integers populated with bit-subfield definitions.

Angus
  • 12,133
  • 29
  • 96
  • 151
  • 2
    What, in your opinion, is the "C API"? And where do I find one of them? – Pete Wilson Sep 12 '11 at 10:48
  • 1
    @Pete wilson:These are the statements from the above link which i could not understand!!! – Angus Sep 12 '11 at 10:51
  • 3
    Right! The whole quote is somewhat off target and misguided, or perhaps just ill expressed. Just pay attention to portability as it relates to word size and you will be fine. In other words, don't make any assumptions about 32- or 64- or n-bitness of the underlying hardware. Instead, use the headers that the compiler writers have been at pains to provide for you. The most important of these, in the context of this question, is limits.h . – Pete Wilson Sep 12 '11 at 10:55
  • 1
    CPU's of diferent architectures (x86 or arm) may represent the bitfield structures diferently. Even if they both are 32-bits, the results may be completly diferent. That was one of the motives that lead me away from bitfields, as i work with arm cpu's. As to the 2 points you couldn't understand, 1 if your bitfield structure is represented by integers (32-bits), you can't have a bitfield longer than 32 bits. 2 - Imagining you have 2 integers, you can't have a 16 bits bitfield with the first 8 bits on one integer and the other 8 on the other. – Nuno V. Sep 12 '11 at 11:13

1 Answers1

4

1.bit fields may be no wider

Let's say you want a bitfield that is 200 bits long.

struct my_struct {
  int my_field:200;  /* Illegal! No integer type has 200 bits --> compile error!
} v;

2.no bit field should overlap the underlying variable boundaries

Let's say you want two 30 bit bitfields and that the compiler uses a 32 bit integer as the underlying variable.

struct my_struct {
  unsigned int my_field1:30;  
  unsigned int my_field2:30; /* Without padding this field will overlap a 32-bit boundary */
} v;

Ususally, the compiler will add padding automatically, generating a struct with the following layout:

struct my_struct {
  unsigned int my_field1:30;  
  :2  /* padding added by the compiler */
  unsigned int my_field2:30; /* Without padding this field will overlap a 32-bit boundary */
  :2  /* padding added by the compiler */
} v;
Klas Lindbäck
  • 33,105
  • 5
  • 57
  • 82