Clang编译器结构体打包问题：始终按2字节填充导致结构体大小不符合预期

嘿，这个问题我之前在嵌入式开发里碰过好几次！你遇到的情况大概率是目标硬件的对齐限制在搞鬼，不是Clang不遵守__attribute__((packed))，而是它不敢——毕竟硬件要是不支持非对齐的32位访问，强行打包会直接导致程序崩溃。

问题根源分析 #

• 硬件对齐限制：比如部分ARM Cortex-M老内核、AVR32这类架构，对32位数据类型有最小2字节的对齐要求。也就是说，哪怕你加了packed属性，编译器也必须把uint32_t类型的成员放到偶数偏移的位置，不然CPU访问这个成员的时候会触发总线错误。所以你的dummy1占1字节后，编译器不得不补1字节，让dummy2从偏移2的位置开始，总大小就成了1+1+4=6字节。
• 编译选项限制：如果你的目标架构其实支持非对齐访问，但你不小心加了-mno-unaligned-access这类禁用选项，Clang也会强制对齐来保证访问安全。

解决办法 #

• 方法一：开启非对齐访问支持（如果硬件允许）
  如果你用的是ARM架构，确保编译时加了-munaligned-access选项（不同架构的选项可能不一样，比如RISC-V是-mno-strict-align），这样Clang就可以无视2字节的对齐要求，真正把结构体打包成5字节。
• 方法二：调整结构体成员顺序
  如果硬件确实不支持非对齐的32位访问，那可以把uint32_t类型的成员放到最前面：

  struct __attribute__((packed)) packed_struct_test
  {
    uint32_t dummy2;
    uint8_t dummy1;
  };
  

  这样dummy2从偏移0的位置开始（天然对齐），dummy1接在后面，packed情况下总大小就是4+1=5字节，而且访问任何成员都不会触发对齐错误。
• 方法三：用字节数组手动处理（迫不得已时用）
  如果你必须保持成员顺序，又要5字节大小，可以把dummy2定义成uint8_t数组，然后在代码里手动通过位运算或者memcpy把它转成uint32_t，绕开编译器的对齐限制：

  struct __attribute__((packed)) packed_struct_test
  {
    uint8_t dummy1;
    uint8_t dummy2[4];
  };
  
  // 读取dummy2的示例
  uint32_t get_dummy2(const struct packed_struct_test* s) {
    uint32_t val;
    memcpy(&val, s->dummy2, sizeof(val));
    return val;
  }
  

验证小技巧 #

你可以写个小测试代码，打印成员的偏移量，确认是不是对齐的问题：

#include <stdint.h>
#include <stdio.h>
#include <stddef.h>

struct __attribute__((packed)) packed_struct_test
{
  uint8_t dummy1;
  uint32_t dummy2;
};

int main() {
  printf("结构体总大小：%zu\n", sizeof(struct packed_struct_test));
  printf("dummy1 偏移量：%zu\n", offsetof(struct packed_struct_test, dummy1));
  printf("dummy2 偏移量：%zu\n", offsetof(struct packed_struct_test, dummy2));
  return 0;
}

如果输出里dummy2的偏移量是2，那就能实锤是硬件对齐限制导致的填充。

最后提醒一句：一定要注意，强行打包成5字节如果违反了硬件对齐规则，访问dummy2时会直接崩溃，所以千万要先确认你的目标平台能不能扛住非对齐的32位访问！

备注：内容来源于stack exchange，提问作者G. B.