相同f2c生成的C代码同版本GCC编译跨平台运行结果不一致

1. 核心错误点 #

问题本质是指针加法运算的类型依赖顺序错误，结合不同平台的结构体对齐规则差异触发：
观察两个宏定义的写法差异：

• 正常运行的v_hhdcb__宏：#define v_hhdcb__ ((shortint *)&dovit_1 + 1608)，是先将&dovit_1强制转换为shortint*类型再执行加法，指针步长固定为sizeof(shortint)=2，不受其他因素影响。
• 异常的v_cncal__宏：#define v_cncal__ ((integer *)(&dovit_1 + 5))，是先对&dovit_1执行加法，再强制转换为integer*，加法的步长完全取决于&dovit_1本身的类型。

2. 类型不一致的根源 #

从给出的代码顺序可以看到dovit_1有两次定义：

1. 初始定义：#define dovit_1 (dovit_._1)，对应类型是包含shortint dovita[1]的结构体
2. 后续重定义：在声明shortint *__dovit后，通过#undef dovit_1改为#define dovit_1 __dovit[0]，对应类型是shortint，&dovit_1类型为shortint*

如果v_cncal__的宏定义是f2c生成在dovit_1重定义之前，那么宏展开时&dovit_1的类型是结构体指针，加法步长等于该结构体的大小。

3. 跨平台差异原因 #

不同平台的默认结构体对齐规则不同：

• HP-UX、AIX、Ubuntu、openSUSE等平台默认对该类仅包含short成员的结构体对齐粒度为2字节，结构体大小为2字节，所以&dovit_1 +5偏移为5*2=10字节，符合预期。
• RHEL8的GCC默认开启了4字节结构体对齐优化（为了兼容旧版RHEL的二进制规范），该结构体大小被填充为4字节，所以&dovit_1 +5偏移为5*4=20字节，出现错误。

这属于f2c的代码生成缺陷：它在生成依赖dovit_1地址的宏时，没有考虑到后续dovit_1会被重定义，也没有按照shortint*类型显式转换后再做加法，导致宏的行为依赖于平台对齐规则，可稳定复现的话可以向f2c维护团队反馈该问题。

临时解决方案除了手动修改宏定义外，也可以在RHEL8的编译选项中加入-fpack-struct=2强制结构体按2字节对齐，不需要修改生成的代码即可正常运行。

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