因此，根据此处的C编译器标准：
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
我们发现无法精确确定在C编译器中如何实现位字段的要求。显然，只要位域的行为与任何其他标量域一样，任何事情都会发生。文档部分6.7.2.1-10说：
“一个实现可以分配任何足够大的可寻址存储单元来容纳一个位域。如果有足够的空间，则紧跟在结构中另一个位域之后的位域应打包到同一单元的相邻位中。如果不足，保留空间，是否将不合适的位字段放入下一个单元或与相邻单元重叠是由实现定义的。一个单元内位字段的分配顺序（高位到低位或低位）到高级）是由实现定义的。可寻址存储单元的对齐方式未指定。”
对于许多声称“您不能信任位域”或“位域不可移植”的人来说，对编译器的迫在眉睫的自由似乎是一站式服务。该警报表明，整个编译器编写者和CPU制造商在星空中密谋，只是因为标准允许而笑着急于做一些奇特的位域调整和对齐。
这些疯狂的波西米亚风格的编译器/ CPU设计人员在哪里致力于保证位域永远不依赖和不便携，这些证据在哪里？我想看看火星上绿人的确凿证据。
我已经附上了简单易懂的C ++源代码，以告诉有关使用C ++编译器的任何系统的位域真相。我要问社区，不是征求意见，而是要向您的系统和编译器提供确切的输出证据，如果它们与发布的结果有所出入。如果与发布的结果相比，我有能力对整个C / C ++社区进行相同/不相同的投票，我想知道百分比是多少？
#include <stdio.h>
/*
A simple program to illustrate the bitfields actual internal compiled layout.
Results depend on machine architecture and compiler implementation and flags.
*/
typedef unsigned long long int ulli;
struct bitf
{
// field bits offset
ulli f0 : 1; // 0
ulli f1 : 2; // 1
ulli f3 : 3; // 3
ulli f7 : 4; // 6
ulli f15 : 5; // …