2

Suppose I have a structure defined as follows: 

typedef struct Counters {
    uint8_t counterSec : 6;
    uint8_t : 3;
    uint8_t counterMin : 6;
    uint8_t : 3;
    uint8_t counterHr : 5;
    uint8_t : 1;
};

As I want to dedicate 6 bits per first two counters and 5 bits per last counter, I end up with 17 bits, which means that a total of 24 bits will be allocated to an instance of Counters-type structure variable. What may be a practical significance of defining empty bit fields such as in the structure above - if there is any?

In response to the duplicity of this question - a similar question has indeed been asked before. The situation in which I encountered empty bit fields relates to microcontroller programming and configuring registers - hence, the question is regarding the use of empty bit fields in that particular situation. Unfortunately, answers on a similar post did not address these question. Hopefully this will justify this question a little bit more :)

avg
  • 223
  • 3
  • 11
  • 3
    bitfields are pure evil, unpredictable. you should never assume the size or bit ordering the compiler chooses for bitfields, there is no way to make that reliable. one version of one compiler will do it the same way every time, unless there are command line options that affect it. But the code is by definition not portable across versions or compilers if bit ordering or spacing or overall size that the fields fit into is a requirement. – old_timer Jan 29 '16 at 02:15
  • 1
    this answer is "it depends", there is no one true answer to this question. – old_timer Jan 29 '16 at 02:16
  • Your assumptions about how many bits will be allocated are unfounded and likely wrong for any given compiler. And what is the purpose of your unnamed bit fields? – Carey Gregory Jan 29 '16 at 02:16
  • i think these fields are protected for internal use by the library – milevyo Jan 29 '16 at 02:53
  • @CareyGregory can you please explain where I went wrong with my assumption - a tutorial on C that I read recently [here] (http://www.tutorialspoint.com/cprogramming/c_bit_fields.htm) mentioned that a bit field divided structure will allocate minimum the number of bits needed to hold the biggest member and expand if necessary to accommodate all bit fields, increasing in similar-sized chunks that are equal to the originally allocated memory space – avg Jan 29 '16 at 04:48
  • @MooseBoys Thanks for pointing it out - indeed I overlooked that question. This question ended up having a great answer from @ bta. hopefully that will help excuse my negligence :) – avg Jan 29 '16 at 04:52
  • @milevyo I am a little confused - what library are you referring to? – avg Jan 29 '16 at 04:58
  • 1
    It's those allocation chunks. They will be hardware and compiler dependent, so your assumption that 24 bits will be used to contain the structure is unfounded. That will be true on some processors with some compilers and some compiler options while untrue in other circumstances. If the resulting size of the element is important to your design, I would not use bit fields. – Carey Gregory Jan 29 '16 at 04:58
  • @CareyGregory does this mean that declaring a variable as uint8_t doesn't necessarily allocate 8 bits in memory? – avg Jan 29 '16 at 05:00
  • You've gone off on a tangent now that I don't understand, but if it does mean that in this circumstance then your `struct` is at least 48 bits. I don't think it is. – Carey Gregory Jan 29 '16 at 05:17
  • @CareyGregory let me try to get back to the original topic - based on what I read in that small article on bit fields is that if variables inside the structure are initialized as bit fields, then a structure can occupy less space than all of the variables if declared separately - the only constraints are on the minimum space allocated for a structure; it is no less than the largest (?) variable inside that structure. So if two variables uint8_t and uint16_t are inside a structure and both are declared as bit fields (that can together fit inside 16 bits), then 16 bits will be allocated (not 24) – avg Jan 29 '16 at 05:41
  • You need to think about this whole issue and ask another question. – Carey Gregory Jan 29 '16 at 06:19
  • 1
    What may be a practical significance of defining empty bit fields?, it's up to your imagination. It is possible in c, so it can be exploited. what can be wrong is the logic that you put. it can be checksome holders, it can be boundaries guards, join multiple structs in an UNION. as i said imagination is the limit. – milevyo Jan 29 '16 at 13:13
  • @CareyGregory Unfortunately, I can't even find the point at which the two of us started talking about different things. Regardless, thank you for your answer - I will revisit it after doing more readings – avg Jan 29 '16 at 23:24
  • @milevyo Great clarification - I am approaching this issue from the perspective of embedded systems programming which indeed uses them as boundaries of a kind. I didn't realize that bit fields were so versatile – avg Jan 29 '16 at 23:27

1 Answers1

5

There are a number of reasons you might see an empty bit field. They might be reserved for some future use, such as expanding the existing fields without having to change their offsets. They may also be there for alignment purposes, padding out to some nice "round" alignment. In structures that get passed to/from hardware registers, you can see empty bit fields because the hardware will mandate the exact bit layout of the structure. Whatever their purpose is, giving the fields a meaningful name will help indicate their purpose.

As a side note, your structure looks a bit off. You are using an 8-bit data type but your fields don't align to any particular boundary. Either change your 3-bit reserved space to 2 bits (so that each pair of fields fits in a uint8_t) or use a single data type like uint32_t that can hold all of your fields in one.

bta
  • 43,959
  • 6
  • 69
  • 99
  • Great answer, thank you! Also, the part about hardware registers is spot on - I came across a structure with empty bit fields in an initialization routine inside a header file when working with an uC. – avg Jan 29 '16 at 04:58
  • 1
    The purpose of unnamed bit fields is clear. What's not clear is why the OP chose such odd numbers for them. – Carey Gregory Jan 29 '16 at 05:22