我读到，结构中位字段的顺序是特定于平台的。如果我使用不同的特定于编译器的打包选项，那该如何保证数据在写入时以正确的顺序存储？例如：
struct Message
{
unsigned int version : 3;
unsigned int type : 1;
unsigned int id : 5;
unsigned int data : 6;
} __attribute__ ((__packed__));
在具有GCC编译器的Intel处理器上，这些字段如图所示布置在内存中。Message.version是缓冲区的前3位，然后Message.type是。如果我为各种编译器找到了等效的struct包装选项，这是否可以跨平台使用？
Answers:
不，它不是完全可移植的。结构的打包选项是扩展程序，它们本身并不完全可移植。除此之外，C99§6.7.2.1第10段说：“单位内位域的分配顺序（从高位到低位或从低位到高位）是实现定义的。”
例如，即使是单个编译器，也可能会根据目标平台的字节顺序以不同的方式安排位字段。
抱歉，编译器之间的位字段差异很大。
使用GCC时，大型字节序机器首先将大端的位置进行排列，而小型字节序机器首先将小端的位置进行排列。
K＆R说：“结构的相邻[bit]字段成员在与实现相关的方向上打包到与实现相关的存储单元中。当另一个字段之后的字段不适合时...可以在单元之间拆分，也可以将该单元拆分为填充。宽度为0的未命名字段强制执行此填充...”
因此，如果需要与机器无关的二进制布局，则必须自己完成。
由于填充，最后一条语句也适用于非位域-但是，所有编译器似乎都具有某种强制结构字节包装的方法，正如我所看到的，您已经为GCC找到了。
应避免使用位域-即使对于同一平台，它们在编译器之间也不易移植。从C99标准6.7.2.1/10-“结构和联合说明符”（C90标准中有类似的措词）：
一个实现可以分配任何足够大的可寻址存储单元来容纳位域。如果有足够的空间，应将紧随结构中另一个位域的位域打包到同一单元的相邻位中。如果剩余空间不足，则将实现不适当的位字段放入下一个单元还是与相邻单元重叠。单位内位域的分配顺序（从高位到低位或从低位到高位）是实现定义的。未指定可寻址存储单元的对齐方式。
您无法保证位字段是否会“跨越”一个int边界，也无法指定位字段是从int的低端还是int的高端开始（这与处理器是大端或小端）。
最好使用位掩码。使用内联（甚至宏）设置，清除和测试这些位。
endianness在谈论字节顺序而不是位顺序。如今，有99％的确定位顺序是固定的。但是，在使用位域时，应考虑字节序。请参见下面的示例。
#include <stdio.h>
typedef struct tagT{
int a:4;
int b:4;
int c:8;
int d:16;
}T;
int main()
{
char data[]={0x12,0x34,0x56,0x78};
T *t = (T*)data;
printf("a =0x%x\n" ,t->a);
printf("b =0x%x\n" ,t->b);
printf("c =0x%x\n" ,t->c);
printf("d =0x%x\n" ,t->d);
return 0;
}
//- big endian : mips24k-linux-gcc (GCC) 4.2.3 - big endian
a =0x1
b =0x2
c =0x34
d =0x5678
1 2 3 4 5 6 7 8
\_/ \_/ \_____/ \_____________/
a b c d
// - little endian : gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
a =0x2
b =0x1
c =0x34
d =0x7856
7 8 5 6 3 4 1 2
\_____________/ \_____/ \_/ \_/
d c b a
可能大多数时候，但不要在农场上打赌，因为如果您错了，您将损失惨重。
如果确实需要完全相同的二进制信息，则需要创建带有位掩码的位域-例如，对Message使用无符号短（16位），然后使用诸如versionMask = 0xE000之类的东西来表示三个最高位。
结构中的对齐方式也存在类似的问题。例如，Sparc，PowerPC和680x0 CPU都是big-endian，Sparc和PowerPC编译器的常见默认设置是在4字节边界上对齐结构成员。但是，我用于680x0的一个编译器仅在2字节边界上对齐-并且没有选择来更改对齐方式！
因此，对于某些结构，Sparc和PowerPC上的大小是相同的，但在680x0上较小，并且某些成员在该结构内的内存偏移量不同。
这是我从事的一个项目的问题，因为在Sparc上运行的服务器进程将查询客户端，并发现它是big-endian，并假定它可以将二进制结构喷射到网络上，而客户端可以应付。而且在PowerPC客户端上运行良好，在680x0客户端上崩溃了很多。我没有编写代码，并且花了很长时间才发现问题。但是一旦完成，就很容易修复。
感谢@BenVoigt对您的非常有用的评论开始
不，创建它们是为了节省内存。
Linux源代码确实使用位字段来匹配外部结构：/usr/include/linux/ip.h对于IP数据报的第一个字节具有此代码
struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
__u8 ihl:4,
version:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
__u8 version:4,
ihl:4;
#else
#error "Please fix <asm/byteorder.h>"
#endif
但是，鉴于您的评论，我正在放弃尝试使此功能适用于多字节位字段frag_off的问题。
当然，最好的答案是使用一个将位字段读/写为流的类。只是不能保证使用C位字段结构。更不用说在现实世界的编码中使用它是不专业/懒惰/愚蠢的。