关于直接用malloc/calloc指针接收realloc返回值是否错误的疑问

为什么说这种写法存在理论风险？ #

有人指出直接用malloc()/calloc()返回的原指针接收realloc()结果是错误的，比如这段代码：

#include <stdlib.h>

int main()
{
    int *malloc_ptr = malloc(5 * sizeof(int));
    malloc_ptr = realloc(malloc_ptr, 10 * sizeof(int));

    return 0;
}

风险点很明确：如果realloc()扩容失败，会返回NULL。这时候原指针malloc_ptr会被覆盖成NULL，导致之前malloc()申请的内存彻底丢失——既没法访问这块内存里的数据，也没法调用free()释放它，直接造成内存泄漏。

正确的安全写法应该用临时指针先接收返回值，判断成功后再更新原指针：

#include <stdlib.h>

int main()
{
    int *malloc_ptr = malloc(5 * sizeof(int));
    int *realloc_ptr = realloc(malloc_ptr, 10 * sizeof(int));

    if (realloc_ptr == NULL) {
        // 处理失败逻辑：比如释放原内存、打印错误日志等
        free(malloc_ptr);
    } else {
        malloc_ptr = realloc_ptr;
    }

    return 0;
}

那为什么很多开发者还是用"不安全"的写法？这些软件都有问题吗？ #

答案是要看具体场景，不能一概而论：

• 极端场景无需处理：很多桌面程序、快速工具默认运行在内存充足的环境，realloc()失败的概率极低。就算真失败了，程序直接崩溃退出也不会造成严重后果——毕竟短运行时间内的内存泄漏影响可以忽略。
• 原型/小代码优先效率：写快速原型、脚本化小工具时，开发者更在意代码简洁快速实现，不会为极低概率的错误场景增加代码复杂度。
• 开发者认知不足：部分开发者没意识到这个风险，或者觉得"反正程序跑起来没问题"，忽略了健壮性要求。

但要明确：在高可靠性要求的程序（比如后台服务、嵌入式系统、长时间运行的进程）里，这种写法就是严重问题——内存泄漏会随着运行时间积累，最终导致程序崩溃或系统资源耗尽。

所以结论是：这种写法本身存在健壮性缺陷，但是否算"软件问题"取决于程序的应用场景。从工程严谨性的角度，推荐始终使用安全写法。

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