前段时间我从互联网上下载了一个源代码。有几个malloc调用，之后没有检查NULL。据我所知，你需要在调用malloc后检查NULL。
有人在调用malloc后没有检查NULL是否有充分的理由？我错过了什么吗？
答案 0 :(得分：6)
人们不会检查，因为他们是懒惰的，这使他们的代码更加丑陋，他们不想弄清楚如何从各处的错误中恢复。
我听过一些程序员说，“如果我不能对某个块进行malloc，那么系统很快就会崩溃，因为VM已经满了，那我为什么要费心去检查？”
我不同意。您应该检查错误，即使这意味着只记录错误并调用exit（）或抛出异常。虽然我们趋向于拥有巨大磁盘和永远在线分页存储器的系统，但业界已经出现问题，现在我们拥有内存有限且没有按需分页的智能手机和平板电脑。甚至在桌面上我们的数据集也增长了很多，有时malloc会失败。
如果您不想在任何地方添加额外的代码行，只需编写自己的malloc替换函数，调用malloc并检查错误并使用它代替malloc。
答案 1 :(得分：6)
正如Jens Gustedt在评论中提到的，当malloc()返回错误时，您的程序可能已经陷入了一堆麻烦。当程序很可能无论如何都无法做任何事情时，放入一堆错误处理代码来处理这种情况是否有意义？对于许多程序，答案可能是“不”，对于其他程序，做一些适当的事情可能非常重要。
您可以尝试通过简单的'malloc-or-die'包装函数来分配内存，以保证分配成功或程序将终止：
void* m_malloc(size_t size)
{
void* p;
// make sure a size request of `0` doesn't trigger
// an error situation needlessly
if (size == 0) size = 1;
p = malloc(size);
if (!p) {
// attempt to log the error or whatever
abort();
}
return p;
}
然后遇到的一个问题是除了可能终止程序之外，没有什么可以做到的。即使记录问题也可能需要一些内存分配，因此日志工具可能会有自己的问题（除非你的分配失败是由于尝试分配一个不合理的大块内存）。
您可以尝试通过在程序的早期分配一个“故障安全”块来解决该问题，当您需要记录问题时可以释放（我认为有很多程序使用此策略）。但是，您愿意为此类错误处理投入多少工作取决于您的具体需求。如果您的程序需要确保在malloc()返回错误时完成某些重要的复杂操作，那么您需要有相应的安全措施来确保可以以非常低的价格执行这些操作 - 记忆情况。通常这意味着额外的复杂性，并且可能并不总是值得努力。
答案 2 :(得分：3)
他们只是不关心意外崩溃！
当你做malloc时，你很可能会立即存储东西。因此，如果您不检查NULL，那么程序可能会在尝试存储某些内容时随后崩溃。
在请求少量内存时malloc几乎不会失败的小程序中，这种情况不太可能发生。所以malloc不会返回NULL。
但在我看来，即使在小型程序中，练习 {em} NULL check通常也是好事。
答案 3 :(得分：1)
如果您需要更多记忆而且malloc无法提供更多内容，您可以对此采取任何措施吗？
我想优雅地退出。
但是如果你退出，我猜他们认为你退出的方式并不重要（不妨崩溃和避免，他们认为检查为空的“开销”）。
也许功能是这样的，他们不需要清理代码？
我不同意。您应该在malloc的返回
NULL