64位处理器编译时结构体nas_ftd_umts_nas_info_s_type_v01大小异常原因咨询

这是典型的**编译器内存对齐（structure padding）**导致的现象，本质是编译器为了提升CPU内存访问效率自动插入的填充字节，下面结合你的偏移量输出详细分析：

1. 先看关键成员的类型和对齐要求

   • apn_addr_len是uint16_t类型，在64位GCC这类编译器的默认规则下，2字节的整数类型需要对齐到2字节边界（也就是起始地址必须是2的倍数）。

2. 追踪前面成员的内存占用
   根据你输出的偏移量：

   • pdp_address[10]的起始偏移是51，它的长度是10字节，所以它的结束地址是51 + 10 = 61。
   • 61是奇数，完全不符合uint16_t的2字节对齐要求——CPU访问非对齐的2字节数据时，需要拆分两次内存读取，效率会大幅下降。

3. 编译器插入填充字节的位置
   为了让apn_addr_len满足对齐要求，编译器会在pdp_address数组的末尾自动插入1字节的填充，把apn_addr_len的起始地址推到62（偶数，符合2字节对齐）。这就是你看到的额外1字节的来源。

4. 验证整体内存占用

   • apn_addr_len占2字节，结束地址是62 + 2 = 64，正好对应你输出的apn_address的起始偏移64。
   • apn_address[20]从64开始，占用20字节，最终整个结构体的总大小是64 + 20 = 84，和你输出的sizeof(info)结果完全匹配。

补充说明 #

内存对齐是编译器的默认优化策略，目的是让CPU能更高效地访问内存——对齐的内存地址可以让CPU一次性完成数据读取，不需要额外的拆分操作。如果想要强制取消这种填充，可以使用编译器的特定属性（比如GCC的__attribute__((packed))），但要注意：这种操作可能会降低程序性能，甚至在某些架构下触发未定义行为，需要谨慎使用。

内容的提问来源于stack exchange，提问作者user1237538