使用-Os优化时GCC错误判定指针为NULL的原因咨询

近期升级到较高版本GCC后，在使用-Os尺寸优化编译时，某函数被完全优化为空指针访问陷阱代码。经测试，该问题从GCC 11.1版本的-Os优化开始出现，但使用-O2、-O3优化（即使开启-fstrict-aliasing）时运行正常。

简化复现代码 #

#include <inttypes.h>
#include <stddef.h>
#include <string.h>

typedef struct bounds_s {
  uint8_t *start;
  uint8_t *end;
} bounds_s_t;

static void reserve_space(bounds_s_t *bounds, size_t len, uint8_t **element)
{
  if (bounds->start + len > bounds->end) {
    return;
  }
  
  *element = bounds->start;
  bounds->start += len;
}

void bug(uint8_t *buffer, size_t size)
{
  bounds_s_t bounds;
  uint32_t *initialize_this;
  
  initialize_this = NULL;
  bounds.start = buffer;
  bounds.end = buffer + size;

  reserve_space(&bounds, sizeof(*initialize_this), (uint8_t **)&initialize_this);

  uint32_t value = 1234;
  memcpy(initialize_this, &value, sizeof(*initialize_this));
}

生成的汇编代码 #

bug:
        xor     eax, eax
        mov     DWORD PTR ds:0, eax
        ud2

问题解答 #

1. 为什么GCC判定initialize_this始终为NULL？ #

核心原因是代码违反了C标准的严格别名规则，触发未定义行为后，GCC在-Os优化下激进地利用规则做了极端优化。

严格别名规则规定：不同非字符类型的指针不能用来访问同一块内存区域。你将uint32_t **强制转换为uint8_t **并传入reserve_space函数，在函数内部通过uint8_t **修改了原本是uint32_t *类型的initialize_this变量——这种跨类型的内存访问完全违反规则，属于未定义行为。

GCC在-Os（优先优化代码尺寸）模式下，会更激进地应用基于严格别名规则的优化：它认为通过uint8_t **修改initialize_this的操作是无效的，直接忽略这个修改，因此判定initialize_this始终保持初始值NULL。

而-O2/-O3下运行正常只是巧合——这两种优化模式更侧重执行速度，可能因其他优化逻辑（比如代码路径的分析优先级）没有触发这个极端的未定义行为优化，但这并不代表代码正确，未定义行为随时可能导致各种异常。

2. 强制转换是否违反严格别名规则？ #

是的，这种强制转换完全违反了严格别名规则。

严格别名规则允许的例外只有两种情况：

• 使用char/unsigned char类型的指针访问任意类型的内存（用于字节级操作）；
• 通过void*指针进行类型转换（void*是通用指针类型，转换到其他指针类型是标准允许的）。

但你这里的操作是将uint32_t**转成uint8_t**，然后通过后者修改前者指向的uint32_t*变量——这不属于上述例外，直接违反规则。

修复建议 #

• 方案1：修改reserve_space的参数类型为void**
  把函数参数改为void** element，调用时传入(void**)&initialize_this，函数内部再将*element转换为uint8_t*赋值。void*的转换是标准允许的，不会触发严格别名问题。
• 方案2：返回分配的指针
  让reserve_space返回uint8_t*类型的指针，调用时直接赋值给initialize_this（需要强制转换为uint32_t*），避免使用输出参数的类型转换。
• 方案3：用unsigned char中转
  如果必须保留原函数签名，可以将&initialize_this转换为unsigned char*传入，在reserve_space内部通过字节拷贝的方式修改initialize_this的值，但这种方式代码可读性较差。

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