为什么 C 中的 `free` 不占用要释放的字节数？

c memory-management malloc free

明确一点：我知道 malloc 和 free 是在 C 库中实现的，它通常从操作系统分配内存块并自行管理以将较小的内存分配给应用程序并跟踪分配的字节数。这个问题不是How does free know how much to free。

相反，我想知道为什么 free 首先是这样制作的。作为一种低级语言，我认为要求 C 程序员不仅要跟踪分配了哪些内存，还要跟踪分配了多少内存是完全合理的（事实上，我通常发现我最终会跟踪字节数无论如何分配）。我还想到，明确地将字节数提供给 free 可能会允许一些性能优化，例如，具有不同分配大小的单独池的分配器将能够仅通过查看输入来确定要释放哪个池论点，并且总体上会减少空间开销。

所以，简而言之，为什么要创建 malloc 和 free 以使它们需要在内部跟踪分配的字节数？这只是历史偶然吗？

一个小编辑：一些人提供了诸如“如果您释放的数量与分配的数量不同怎么办”之类的观点。我想象中的 API 可能只需要一个来准确释放分配的字节数；释放或多或少可以简单地由 UB 或实现定义。不过，我不想阻止讨论其他可能性。

因为跟踪分配本身已经很痛苦，而且如果您还必须跟踪大小，它甚至会使代码更加复杂。

我可以想到几个原因：如果用户不必这样做，为什么还要让他们这样做？如果用户搞砸了怎么办？无论如何，这是一个多余的问题。如果他们做出了其他选择，你仍然会问为什么。

@BoBTFish：这是我们正在谈论的 C，而不是 Python 甚至 C++。用户已经不得不做他不必做的 $h!1 吨。这不是一个原因。

K&R 对此也无话可说。我们可以随意推测，但我认为最初的原因可能是lost in history。

您不能要求程序员正确传递块的大小，因为malloc 的调用者不知道返回的块的大小。 malloc 通常会返回一个大于请求的块。充其量，程序员可以传入 malloc() 调用中请求的大小，这对 free() 的实现者毫无帮助。

igk

单参数 free(void *)（在 Unix V7 中引入）与我在这里没有提到的之前的双参数 mfree(void *, size_t) 相比有另一个主要优势：一个参数 free 极大地简化了每个其他使用堆内存的 API。例如，如果 free 需要内存块的大小，那么 strdup 将不得不返回两个值（指针 + 大小）而不是一个（指针），并且 C 使多值返回比单个返回更麻烦-值返回。我们必须写 char *strdup(char *, size_t *) 或 struct CharPWithSize { char *val; size_t size}; CharPWithSize strdup(char *) 而不是 char *strdup(char *)。（现在第二个选项看起来很诱人，因为我们知道 NUL 终止的字符串是 "most catastrophic design bug in the history of computing"，但这是事后诸葛亮。早在 70 年代，C 将字符串处理为简单 char * 的能力实际上被认为是 {2 }.) 另外，受此问题影响的不仅仅是 strdup —— 它会影响每个分配堆内存的系统或用户定义的函数。

早期的 Unix 设计者是非常聪明的人，free 优于 mfree 的原因有很多，所以基本上我认为问题的答案是他们注意到了这一点并相应地设计了他们的系统。我怀疑你会在他们做出决定的那一刻找到任何关于他们头脑中发生的事情的直接记录。但我们可以想象。

假设您正在用 C 语言编写应用程序以在 V6 Unix 上运行，并带有两个参数 mfree。到目前为止，您的管理还不错，但是随着您的程序 become more ambitious 并且需要越来越多地使用堆分配的变量，跟踪这些指针大小变得越来越麻烦。但是您有一个绝妙的主意：您可以编写一些实用函数，将大小直接存储在分配的内存中，而不是一直复制这些 size_t：

void *my_alloc(size_t size) {
    void *block = malloc(sizeof(size) + size);
    *(size_t *)block = size;
    return (void *) ((size_t *)block + 1);
}
void my_free(void *block) {
    block = (size_t *)block - 1;
    mfree(block, *(size_t *)block);
}

你使用这些新函数编写的代码越多，它们看起来就越棒。它们不仅使您的代码更易于编写，而且还使您的代码更快 -- 这两件事通常不会一起出现！在您到处传递这些 size_t 之前，这增加了复制的 CPU 开销，并且意味着您必须更频繁地溢出寄存器（尤其是对于额外的函数参数），并浪费内存（因为嵌套函数调用通常会导致 size_t 的多个副本存储在不同的堆栈帧中）。在您的新系统中，您仍然需要花费内存来存储 size_t，但只需要一次，而且它永远不会被复制到任何地方。这些可能看起来效率很低，但请记住，我们谈论的是具有 256 KiB RAM 的高端机器。

这让你开心！因此，您与正在开发下一个 Unix 版本的大胡子男人分享您的酷炫技巧，但这不会让他们高兴，只会让他们难过。你看，他们只是在添加一堆像 strdup 这样的新实用程序函数，他们意识到使用你的酷技巧的人将无法使用他们的新函数，因为他们的新函数都使用了繁琐的指针+大小 API。然后这也让你感到难过，因为你意识到你必须在你编写的每个程序中自己重写好的 strdup(char *) 函数，而不是能够使用系统版本。

可是等等！这是 1977 年，向后兼容性要再过 5 年才会发明！此外，实际上没有人真正使用这个晦涩难懂的“Unix”东西，它的名字很淡。 K&R 的第一版现在正在送达出版商，但这没问题——它在第一页上说“C 不提供直接处理诸如字符串之类的复合对象的操作......没有堆……”。在历史的这一点上，string.h 和 malloc 是供应商扩展 (!)。因此，Bearded Man #1 建议，我们可以随心所欲地更改它们；我们为什么不直接将您的棘手分配器声明为 official 分配器？

几天后，Bearded Man #2 看到新的 API 并说嘿，等等，这比以前好，但它仍然在每个分配中花费一个完整的单词来存储大小。他认为这是亵渎神明的下一件事情。其他人都看着他，就像他疯了一样，因为你还能做什么？那天晚上他熬夜并发明了一个新的分配器，它根本不存储大小，而是通过对指针值执行黑魔法位移来动态推断它，并在保持新 API 的同时将其交换。新的 API 意味着没有人注意到切换，但他们确实注意到第二天早上编译器使用的 RAM 减少了 10%。

现在每个人都很高兴：您获得了更容易编写和更快的代码，Bearded Man #1 可以编写一个很好的简单 strdup 供人们实际使用，而 Bearded Man #2 - 相信他已经赢得了他的保留有点——回到messing around with quines。装运它！

或者至少，这就是它可能发生的方式。

错误，以防万一不清楚，这是一种幻想，其中加入了确凿的细节以提供艺术的多样性。与活着或死去的人的任何相似之处纯粹是因为每个人都参与其中kinda looked the same。请不要与实际历史混淆。

你赢了。在我看来，这是最合理的解释（也是最好的文章）。即使这里的一切都被证明是不正确或无效的，这也是对胡须男人的出色描绘的最佳答案。

哇，这个页面上的答案实际上听起来很合理。 +1 来自我。

更好——这个页面上的答案真的很有趣！ +1 也是如此。

我想知道是否有任何著名的 Pascal 系统以类似于微型计算机 BASIC 解释器的方式使用垃圾收集字符串池？ C 的语义不适用于这样的事情，但在 Pascal 中，如果代码维护可跟踪的堆栈帧（许多编译器无论如何都这样做），这样的事情可以很好地处理。