Bit field memory management in C

Question

To understand the memory storage in a bitfield, I created a test program below.

#include <stdio.h> int main() { int a; typedef struct { int b7 : 1; int b6 : 1; int b5 : 1; int b4 : 1; int b3 : 1; int b2 : 1; int b1 : 1; int b0 : 1; } byte; byte ab0 = {0,0,0,0,0,0,0,1}; a = *(int*)&ab0; printf("ab0 is %x \n",a); byte ab1 = {0,0,0,0,0,0,1,0}; a = *(int*)&ab1; printf("ab1 is %x \n",a); byte ab2 = {0,0,0,0,0,1,0,0}; a = *(int*)&ab2; printf("ab2 is %x \n",a); byte ab3 = {0,0,0,0,1,0,0,0}; a = *(int*)&ab3; printf("ab3 is %x \n",a); byte ab4 = {0,0,0,1,0,0,0,0}; a = *(int*)&ab4; printf("ab4 is %x \n",a); byte ab5 = {0,0,1,0,0,0,0,0}; a = *(int*)&ab5; printf("ab5 is %x \n",a); byte ab6 = {0,1,0,0,0,0,0,0}; a = *(int*)&ab6; printf("ab6 is %x \n",a); byte ab7 = {1,0,0,0,0,0,0,0}; a = *(int*)&ab7; printf("ab7 is %x \n",a); return 0; } 

Compile and run

 gcc -Wall test.c ./a.out ab0 is 80 ab1 is 40 ab2 is 20 ab3 is 10 ab4 is 8 ab5 is 4 ab6 is 2 ab7 is 1 

The same output when I run the code on the Internet http://codepad.org/ntqyuixp

I can not understand his conclusion.

Expected Result: In my understanding, the output should be similar to

 ab0 is 1 ab1 is 2 ab2 is 4 ab3 is 8 ab4 is 10 ab5 is 20 ab6 is 40 ab7 is 80 

• Please let me know what I am missing.

• Is there any role in this?

• How should code be written for my expected behavior?

Answer 1

The order of the bits in the bit field is determined by the implementation. Implementation has a different definition from what you expected, and that almost everything can be said about it.

Almost everything about bit fields is determined by the implementation.

ISO / IEC 9899: 2011 §6.7.2.1 Structure and union specifications

¶4 The expression defining the width of the bit field must be an integer constant expression with a non-negative value that does not exceed the width of the object the type to be specified, a colon and the expression are omitted. ¹²²⁾ If the value is zero, the declaration does not have a declarator.

¶5 The bitfield must be of a type that is a qualified or unqualified version of _Bool , signed int , unsigned int or another specific implementation type. this implementation - determines whether atomic types are allowed.

...

¶9 A structure or union element can have any complete object type other than the changed type. ¹²³⁾ In addition, a member may be declared to consist of a specified number of bits (including a sign bit, if any). Such a member is called a bit field; ¹²⁴⁾ a colon precedes its width.

¶10 A bit field is interpreted as having an integer with or without a sign, consisting of the specified number of bits. ¹²⁵⁾ If a value of 0 or 1 is stored in a bit field with a non-zero width type _Bool , the value of the bit field must be compared with the stored value; a _Bool bit field has the semantics of a _Bool .

¶11 An implementation can allocate any storage address block large enough to hold a bit field. If there is enough space left, a bit field that immediately follows another bit field in the structure should be packed into adjacent bits of the same block. If there is not enough space, then whether a bit field that does not fit will fit in the next block or overlap adjacent units is determined by the implementation. The order of distribution of bit fields within a unit (from high order to low or low order) is determined by the implementation. The alignment of the storage address block is not indicated.

¶12 Declaring a bit field without a declarator, but only a colon and a width, indicates an unnamed bit field. ¹²⁶⁾ As a special case, an element of the structure of a bit field with a width of 0 indicates that the additional bit field should not be packed into a block in which the previous bit field, if any.

¹²²⁾ As long as the number of bits in the _Bool object _Bool not less than CHAR_BIT , the width (number of icons and value bits) of _Bool can be only 1 bit.

^{123) A} structure or union cannot contain an element with a changed type because member names are not regular identifiers, as defined in 6.2.3.

^{124) The} unary operator & (address) cannot be applied to a bitfield object; thus, there are no pointers to or arrays of bitfield objects.

¹²⁵⁾ As indicated in clause 6.7.2 above, if the actual specifier of type int or typedef-name used is defined as int , then it is determined by the implementation whether the -field bit is signed or unsigned.

¹²⁶⁾ The structure element of an unnamed bit field is useful for filling to match external overlays.

Note ¶11 in particular:

The order of distribution of bit fields within a block (from high to low or low order) is determined by the implementation.

Note also that “implementation defined” means that the implementation must determine what it does. That is, you can check the documentation, and the documentation should tell you what the compiler does (if the compiler complies with the standard). This differs from the “unspecified” and some other terms that you will come across - the compiler-writer will almost certainly not change the behavior of bit fields accidentally from release to release. On the contrary, the method of evaluating the arguments of functions, for example, can vary from release to release or in accordance with optimization parameters selected at compile time, etc.

§6.5.2.2 Functional calls

After evaluating the function pointer and the actual arguments, there is a point in the sequence, but before the actual call. Each estimate in the calling function (including other function calls) that is otherwise not separately secreted before or after the body of the called function is executed is indefinitely ordered with respect to the execution of the called function. ⁹⁴⁾

⁹⁴⁾ In other words, the execution of functions does not alternate with each other.

6.7.2 Type Specifiers

5 Each of the multisets, separated by commas, denotes the same type, except that for bit fields it is determined by the implementation, whether the specifier int the same type as signed int or the same type as unsigned int .

Answer 2

the bit is not carried and depends on the machine.

Bit Field Limitations

When using bit fields, be aware of the following issues:

• The code will not be portable, since the organization of bit-by-bytes and bytes within a word is machine dependent .
• You cannot take the address of a bit field; therefore, the expression & mystruct.x is illegal if x is an identifier for a bit field, because it does not guarantee that mystruct.x is on the byte address.
• Bit fields are used to pack more variables into smaller data space, but causes the compiler to generate additional code to manipulate these variables. It stands in terms of code size and runtime.