重分配已有指针到SIZE_MAX未设ENOMEM，但重分配NULL正常？

核心矛盾点 #

自定义my_realloc存在行为不一致：

• 传入NULL指针+SIZE_MAX：正确返回NULL并设置errno=ENOMEM
• 传入有效已分配指针+SIZE_MAX：返回NULL但未设置errno=ENOMEM
• 传入有效指针+SIZE_MAX+1：符合预期设置errno=ENOMEM
  标准realloc与jemalloc无此问题，环境为M1 Mac（arm64架构）

可能的技术原因 #

1. 无符号整数溢出触发错误分支跳过 #

当处理已分配指针时，你的实现大概率需要计算「元数据大小 + 请求大小」的总内存需求：

• 例如代码中有total_size = sizeof(block_header) + size;，当size=SIZE_MAX时，该加法会因无符号整数溢出得到一个极小的正数（arm64下为sizeof(block_header)-1）
• 这个溢出后的数值会被判定为合法内存大小，跳过错误检查逻辑，自然不会设置ENOMEM
• 而SIZE_MAX+1会直接溢出为0，你的实现可能将0识别为非法请求（比如不符合最小分配单元要求），提前触发错误处理流程，正确设置errno

反观NULL指针场景：此时实现直接走「类似malloc」的分支，仅检查请求大小本身，未涉及元数据相加，SIZE_MAX被正确识别为超出可分配上限，因此设置ENOMEM。

2. 非法大小的比较逻辑漏洞 #

代码中可能存在错误的无符号比较逻辑：

• 若用if (size + sizeof(header) > SIZE_MAX)判断是否溢出，SIZE_MAX + sizeof(header)会溢出为远小于SIZE_MAX的值，导致条件不成立，错误认为内存需求合法
• 正确的溢出判断应该是if (size > SIZE_MAX - sizeof(header))，先检查size是否会导致后续加法溢出，而非直接相加后比较

3. 原地扩容的错误处理 #

若你的realloc实现支持原地扩容（即尝试在原有内存块后追加空间）：

• 当请求SIZE_MAX时，可能先尝试调用系统接口（如sbrk或mmap）扩容，但系统返回错误后，你的代码未正确捕获该错误并设置errno
• 而SIZE_MAX+1被提前判定为非法请求，未走到系统调用步骤，直接触发错误处理

4. 元数据读取后的逻辑误判 #

若实现依赖原有内存块的元数据（如已分配大小）进行扩容决策：

• 当原有块大小 + 扩容所需空间的计算发生溢出，可能误判为可以原地扩容，进而跳过全局内存检查，最终系统分配失败时未处理errno

验证与修复建议 #

• 在my_realloc中添加调试日志，打印size、计算后的total_size、系统调用返回值及当前errno，定位具体哪一步跳过了错误设置
• 重构所有涉及size_t的加法运算，用前置溢出检查替代溢出后比较：比如将if (a + b > SIZE_MAX)改为if (a > SIZE_MAX - b)
• 对齐标准realloc逻辑：无论传入指针是否有效，只要请求大小为SIZE_MAX（或超出系统可分配上限），直接返回NULL并设置errno=ENOMEM
• 检查系统调用（如mmap、sbrk）的返回值，确保任何分配失败的场景都正确设置errno

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