使用 realloc 安全吗? [英] Is it safe to use realloc?
问题描述
前段时间我的一个朋友告诉我不要使用 realloc 因为它不安全，但他不能告诉我为什么，所以我对这个主题和最近的参考我的怀疑是:
Some time ago a friend of mine told me not to use realloc because it's unsafe, but he couldn't tell me why, so I made some research on the subject and the nearest references to my doubt were:
我想知道我是否可以继续在我的代码中使用 realloc 或者它是否不安全有没有其他方法可以重新分配内存?
I want to know if I can continue to use realloc in my code or if it's unsafe is there any other way to reallocate memory?
推荐答案
这两篇链接文章中的第一篇提出了两个投诉，超出了此处已经提出的检查呼叫成功"要点.
The first of the two linked article raises two complaints above and beyond the "check the call succeeded" points already raised here.
完成后，旧内容将被丢弃并留在内存中的某处.对于需要擦除所有数据痕迹的安全内存应用程序，这种行为是不合适的.
When this is done, the old contents are discarded and left in memory somewhere. For secure memory applications where it is important to erase all traces of data, this behavior is inappropriate.
这是一个有效的点如果您碰巧存储了敏感数据(例如私钥、未散列的(！)密码等)并希望使漏洞更难恢复数据或其他系统上的进程来窃取数据.
This is a valid point if you happen to be storing sensitive data (e.g. private keys, unhashed(!) passwords etc.) and want to make it harder for exploits to recover the data or other processes on the system to steal the data.
由于它会移动内存，因此指向该内存的任何旧指针都会变得无效，并可能导致程序崩溃或出现其他错误行为.
Since it moves memory around, any old pointers to that memory become invalid and could cause the program to crash or otherwise misbehave.
这点对我来说似乎是无稽之谈.他们提出的解决方案也好不到哪里去，他们malloc()，复制然后free() 具有相同净效果的原始文件 - 地址已更改.如果您想避免移动内存，您可能可以使用一些特定于平台的调用来做到这一点，前提是您安排在它们附近有足够的空闲地址空间.如果您先验知道要保留多少地址空间，那么您可能不会首先考虑调用 realloc() ！
This point seems like nonsense to me. Their proposed solution is no better, they malloc(), copy and then free() the original which has the same net effect - the address has changed. If you wanted to avoid moving the memory you might be able to use some platform specific calls to do that, if you arranged for there to be sufficient free address space near them. If you knew a priori how much address space to reserve then you'd probably not be thinking of calling realloc() in the first place though!
如果你赌 realloc() 永远不会移动，总是在增长，那么你可能有更大的问题需要担心并切换到 malloc() +copy + free() 不可能解决这个问题.
If you're gambling on realloc() never moving, always growing then you've probably got bigger problems to worry about anyway and switching to malloc() + copy + free() can't possibly solve that.
除了正确检查您的返回值点"之外，第二篇文章中最有趣的一点是关于以下内容的警告:
Besides the "check your return value properly point", the most interesting point from the second article is a warning about:
不要一次重新分配 1 个字节的缓冲区.
Do not realloc your buffer by 1 byte at a time.
他们警告:
这肯定会搅动你的内存堆
This is guaranteed to churn your memory heap
这是一个潜在有效的观点，但这并不是对realloc() 本身的批评；如果您使用 malloc()+copy+free()，也会发生同样的情况.真正的解决方法是合理地增加缓冲区，无论您如何增加它们，或者更好地预先分配正确大小的块.
This is a potentially valid point, but it's not a criticism of realloc() itself; the same would happen if you used malloc()+copy+free(). The real fix is to grow buffers sensibly regardless of how you grow them or better yet allocate in correct sized chunks up front.
他们也有一个观点
使用 realloc 将内存返还给系统.
Using realloc to return memory to the system.
他们在这里是正确的，因为使用 0 以外的任何大小可能实际上不会返回.它可能不会让事情变得更糟，但这种用法似乎仍然是过早优化"的一个例子.再次修复是使用合理大小的分配开始.
They're correct here in that using any size other than 0 might not actually make a return. It probably makes things no worse, but this usage still seems like an example of premature "optimisation". The fix again is to use sensible sized allocations to begin with.
排序答案:这不是不安全，但也不是解决所有问题的神奇方法.
Sort answer: it's not unsafe, but it's not a magical solution to all your problems either.
这篇关于使用 realloc 安全吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
