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

Question

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

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

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

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

Answer 1

单参数 free(void *)(在 Unix V7 中引入)与之前的双参数 mfree(void *, size_t) 相比有另一个主要优势，我在这里没有看到它:一个参数 free 极大地简化了所有其他与堆内存一起使用的 API。例如，如果 free 需要内存块的大小，那么 strdup 将不得不以某种方式返回两个值(指针 + 大小)而不是一个(指针)，并且 C 使多值返回比单值返回要麻烦得多。我们必须写 char *strdup(char *) 或 char *strdup(char *, size_t *) 而不是 struct CharPWithSize { char *val; size_t size}; CharPWithSize strdup(char *) 。 (现在，第二个选项看起来很诱人，因为我们知道以 NUL 结尾的字符串是 "most catastrophic design bug in the history of computing" ，但这是事后的看法。早在 70 年代，C 将字符串作为简单的 char * 处理的能力实际上被认为是 defining advantage over competitors like Pascal and Algol，它。受此问题影响的不仅仅是 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 版本的大 mustache 男士分享了您的酷炫技巧，但这并没有让他们高兴，反而让他们感到难过。你看，他们只是在添加一堆新的实用函数，比如 strdup ，他们意识到使用你很酷的技巧的人将无法使用他们的新函数，因为他们的新函数都使用笨重的指针+大小 API。然后让你伤心过，因为你意识到你必须自己重写好 strdup(char *)功能在每次你写的程序，而不是能够使用的系统版本。
但是等等!这是 1977 年，再过 5 年都不会发明向后兼容性!此外，没有人真正使用这个晦涩难懂的“Unix”的东西和它的离色名称。 K&R 的第一版现在正在出版的路上，但这没问题——它在第一页上说“C 不提供直接处理复合对象(如字符串)的操作......没有堆……”。在历史上的这一点上， string.h 和 malloc 是供应商扩展 (!)。因此，建议 Bearded Man #1，我们可以随心所欲地改变它们；为什么我们不直接将您棘手的分配器宣布为官方分配器？
几天后，Bearded Man #2 看到新的 API 并说嘿，等等，这比以前好多了，但它仍然在每个分配中花费一整字来存储大小。他认为这是亵渎神明的下一件事情。其他人都像看疯子一样看着他，因为你还能做什么？那天晚上，他熬夜发明了一个新的分配器，它根本不存储大小，而是通过对指针值执行黑魔法位移来动态推断它，并在保持新 API 到位的同时将其交换。新的 API 意味着没有人注意到这一切换，但他们确实注意到第二天早上编译器使用的 RAM 减少了 10%。
现在每个人都很高兴:你得到了更容易编写和更快的代码，Bearded Man #1 可以编写一个简单的 strdup，人们会实际使用它，而 Bearded Man #2 —— 相信他已经赢得了一点时间- 回到 messing around with quines 。发货吧!
或者至少，这就是它发生的方式。