我正在使用ARM交叉工具链arm-none-ebi-gcc为嵌入式系统编码。 因为代码运行的是 freeRTOS，它有自己的堆内存管理，所以我想在 libc 中覆盖 malloc((、free(( 和 realloc(( 并简单地包装它们以调用 freeRTOS 中的函数。 只有一个问题，freeRTOS 没有 realloc((，这很奇怪，但我的代码肯定需要它。 所以我想了解，如果我只覆盖 malloc(( 和 free(( 但仍然保持 realloc(( 在 libc 中的版本会发生什么？ 另外，我觉得提供我自己的 realloc(( 只是用新大小调用 malloc(( 并在分配新内存块后执行 memcopy，在我看来看起来不够安全，因为新大小通常大于我的应用程序中的旧大小，所以当我做一个大小大于实际分配的内存块的 memcopy(( 可能会产生一些指针访问错误， 这可能吗？
提前谢谢。 -木本
部分替换分配器(替换某些函数但不替换其他函数(不起作用。在最坏的情况下，您将从一个实现中得到严重的堆数据结构损坏，将另一个实现解释为自己的数据结构。如果这样做，可以对此进行强化，以便事情在运行时无法链接或无法分配(提供空指针结果(，我在 musl libc 中做到了这一点，如以下提交中所述：
- https://git.musl-libc.org/cgit/musl/commit/src/malloc?id=c9f415d7ea2dace5bf77f6518b6afc36bb7a5732
- https://git.musl-libc.org/cgit/musl/commit/src/malloc?id=618b18c78e33acfe54a4434e91aa57b8e171df89
- https://git.musl-libc.org/cgit/musl/commit/src/malloc?id=b4b1e10364c8737a632be61582e05a8d3acf5690
但我怀疑许多其他实现采取了相同的预防措施。它们不会帮助你想要的实际工作;他们只会防止灾难性的结果。
如果你真的需要realloc，你将不得不为你正在采用的实现做一个工作。最简单的方法是让它只malloc、memcpy和free，但实际上你需要一种方法来确定要传递给memcpy的长度参数。如果你只是传递新的长度，那么在没有MMU的微控制器上可能是安全的，只要你的长度不是太大，它们可能会跑到MMIO范围或其他东西。但正确的做法是充分阅读malloc实现，以了解其存储位置分配的大小，并编写自己的代码来提取它。此时，您可以使用memcpy编写正确/有效的realloc。