Thread: Bitfields

    #1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2012
    Posts
    21
    Rep Power
    0

    Bitfields


    Hello.
    I am currently updating a project that uses bitfields heavily. To do this I am planning to use these as well. My question is if the following is correct, appropriate or a good idea:


    first a field in the bitfield:


    Code:
    struct {
    WORD somefield:1;
    WORD otherfield :1;
    
    
    WORD MYFIELD:2; // The 2-bit field I am going to use
    
    
    } somebitfield;
    Yeah, I know the standard recommends only use unsigned ints for that, but for some reason the project uses a user defined WORD.


    Ok, so I have a 2-bit field so I guess it means this can assume 4 values right?


    So I define something like


    Code:
     enum { NOTHING=0, STATEONE, STATETWO,STATETHREE} myenum;

    So, my question is , can I safely do something like


    Code:
    
    if(somebitfield.MYFIELD==NOTHING) {
    
    
    }
    elseif (somebitfield.MYFIELD==STATETWO){
    
    
    }

    or even


    Code:
    
    switch(somebitfield.MYFIELD)
      {
       case NOTHING:   
    
    
      case STATEONE:
    
    
    }

    any advice will be greatly appreciated


    Thanks


    Kansai
  2. #2
  3. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Posts
    4,417
    Rep Power
    1871
    > Ok, so I have a 2-bit field so I guess it means this can assume 4 values right?
    Yes.

    But since you seem to imply that WORD is a signed type, the 4 values you have are
    -2 -1 0 1

    For a :1 bitfield, all you have is -1 and 0

    If WORD is actually unsigned, then your enum would work just fine, either as if/else or switch/case.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper
  4. #3
  5. Contributing User
    Devshed Demi-God (4500 - 4999 posts)

    Join Date
    Aug 2011
    Posts
    4,996
    Rep Power
    481
    I'm sure you can find a compiler option that dumps all the macros so you can easily find out what WORD means. Of course, it might be a typedef, so that won't help.

    try gcc -E
    then search the output.

    Find out what WORD is. salem reads into your post that you think WORD is a signed type. (I wouldn't have guessed that the bitfields were likewise signed! I learned something.)

    I read into your post that you're clueless. So find out!
    [code]Code tags[/code] are essential for python code and Makefiles!
  6. #4
  7. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2012
    Posts
    21
    Rep Power
    0
    thanks for the replies.
    I already implemented the solution and it works great. I was just a little aprehensive about bitfields and enums since I seldom use them.

    Anyway, yeah I checked WORD and it was unsigned so it works fine with the values of the enum.


    BY THE WAY, talking about bit fields. The standard recommends to use only unsigned ints. However my legacy code uses WORD and sometimes BYTE (another user defined type)

    Since bit fields are just that: bits, I always wonder what for are these types? I mean for example:

    Code:
    struct{
            unsigned int field1:1;
            unsigned int field2:2;
           ...
    field1 is just one bit, and field2 just two bits. Then why put the "int" there???

    Any answer? :confused:
  8. #5
  9. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Posts
    4,417
    Rep Power
    1871
    Some compilers use the type as a hint to choosing the underlying storage.
    Eg.
    Code:
    #include<stdio.h>
    struct foo {
        unsigned char b1:5;
        unsigned char b2:5;
        unsigned char b3:5;
        unsigned char b4:5;
        unsigned char b5:5;
    };
    struct bar {
        unsigned int b1:5;
        unsigned int b2:5;
        unsigned int b3:5;
        unsigned int b4:5;
        unsigned int b5:5;
    };
    
    int main(){
        printf("%lu %lu\n", sizeof(struct foo), sizeof(struct bar) );
        return 0;
    }
    
    $ gcc foo.c
    $ ./a.out 
    5 4
    Since it can't fit two :5 fields in a byte, it has to allocate a new byte for each field.
    An int on the other hand can pack many :5 fields together, so the overall storage space is less.

    However, this is what the C99 standard says
    An implementation may allocate any addressable storage unit large enough to hold a bit-
    field. If enough space remains, a bit-field that immediately follows another bit-field in a
    structure shall be packed into adjacent bits of the same unit. If insufficient space remains,
    whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is
    implementation-defined. The order of allocation of bit-fields within a unit (high-order to
    low-order or low-order to high-order) is implementation-defined. The alignment of the
    addressable storage unit is unspecified.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper

IMN logo majestic logo threadwatch logo seochat tools logo