严格地说，C标准是否要求必须在malloc之后调用free？当不满足此要求时，它规定了什么？

发件人：

返回的指针必须用free（）或realloc（）解除分配

发件人：

返回的指针必须用free（）或realloc（）解除分配

严格地说，为什么必须释放返回指针

现在我知道POSIX要求在程序终止时释放内存，因此实际上调用

malloc

并立即终止不会造成任何伤害。但这不是我要问的

---

这是C标准中的硬性要求（“必须解除分配”），还是cppreference贡献者的发明，以敦促程序员不要泄漏内存？如果标准中存在这样一个硬要求，这是否意味着，根据C标准（POSIX和其他操作系统相关的东西除外！），如果

malloc

返回的指针不是

free

'd，那么程序就是UB，或者标准是否定义了不满足此要求的后果？（这将特别有趣，因为这可能意味着标准处理程序已经终止时发生的事情！）

C不要求您在分配后释放（）内存

副作用是内存泄漏。但您永远不会看到任何错误或警告。这是你作为程序员要解决的工作。

当他们在cppreference.com上说“返回的指针必须免费处理”时，他们并不意味着程序员必须这样做。它的意思更像是“当分配的内存被释放时，必须使用free或realloc来完成，因为只有那些函数才能正确地完成。”在实际规范中没有这样的命令。

，而

realloc（）

和

free（）

将是C中释放内存的最自然的方式，在C++中释放内存最自然的方式是<代码>删除>代码>。虽然链接页面用C描述行为，但该语言与用C++描述行为的页面是平行的：

成功时，返回指向新分配内存开头的指针。返回的指针必须用std:：free（）或std:：realloc（）解除分配

---

<> P> >我想，C++描述的文本的目的是要明确，其他存储释放手段，包括<代码>删除>代码>，不适合用于从 STD:：MaloC < /C> >或<代码> STD:：CaloLc < /C> >。在描述C时，同样的文字也出现了，尽管C缺乏任何其他预期的工作方式。

不，绝对不需要释放任何内存。这样做是为了您自己，允许实现再次使用它来满足将来对malloc的调用

此外，C对您的机器/操作系统在C程序之外或终止后的状态没有任何说明。指定这一点取决于操作系统或管理它的标准，在实践中，对于任何多进程操作系统，malloc和其他类似资源获得的内存在进程终止时都会消失。

返回的指针必须用free（）或realloc（）解除分配这句话在中不存在

严格地说，标准根本没有规定必须释放对象。它甚至没有明确指出内存块需要通过

free

或

realloc

释放-只是标准没有提供任何其他可用于释放空间的功能

但是，也不能保证它们在程序退出时被释放——相反，所有语言都允许通过

main

进入的程序仍然可以通过不调用

free

泄漏内存，并且仍然在一致的实现上运行。标准规定：

2对象的生存期是程序执行的部分，在此期间保证为其保留存储。对象存在，具有恒定地址33），并在其整个生存期内保留其最后存储的值。34）如果对象在其生存期之外被引用，则行为未定义。当指针指向（或刚刚经过）的对象到达其生命周期结束时，指针的值将变得不确定

以及：

已分配对象的生存期从分配到解除分配

---

就这样。C标准与程序执行终止后发生的任何事情无关。这是一种未被省略定义的行为，因此可能的行为符合标准。

在某些嵌入式应用程序中，永远不会终止，可能是调用malloc（），但永远不会释放（），以建立将永远存在的内部数据结构，或者直到有人拔出电源线。因此，在这种情况下，不可能满足释放已分配内存块的要求。我一直认为，这句话是这样说的：“如果你想释放内存，你必须使用

free（）

或

realloc（）

”。我想重点不在“必须”，而在“自由”。块释放后，必须使用功能

free

。另请参见中的答案，引用的段落不在C标准中。我也找不到类似的东西。我不知道，也许有人会想到用

munmap

或

sbrk

来代替

free

？我觉得这不太可能，though@gaazkam：实现可能提供其他释放内存的方法，但该标准仅提供了free和realloc（）。在malloc之后使用sbrk会导致未定义的行为：@mnistic:这是Unix或其他实现sbrk的系统的问题；当然，这就是为什么把这两个函数混合在一起是个坏主意