如果这是一个坏主意，如何在函数中分配内存？
这不是一个“坏主意”，而是“有时候是一个坏主意”，可以说是编程中的许多想法。
顺便说一下，在函数内部分配内存并将其释放到外部可能是一种常见的设计模式。考虑：
// hashtable is a typedef-ed pointer type
hashtable ht = hashtable_new();
// .. do something with hashtable
hashtable_free(ht);
ht被分配在一个函数hashtable_new中并在它之外发布，但你会在许多好的C代码中反复看到这种模式。
然而，它所表明的是同一逻辑单元（散列表ADT）如何处理分配和解除分配。这很有意义 - 因为知道如何分配的人，最了解如何解除分配。在不同的逻辑单元中分配和释放通常是个坏主意。
如果我们改回它，这个问题最容易回答：
malloc在同一函数中也是freed，为什么这可能是一个好主意呢？答案是，没有内存泄漏或悬空指针，没有任何其他功能的合作就可以实现这一有价值的结果。因此，更容易获得正确的代码，并且该函数具有简单的界面。
现在，如果一个函数调用malloc而不是free怎么办？然后必须有关于谁有义务释放内存，允许完成以及何时需要完成的规则。这些规则成为函数接口的一部分，任何调用该函数的人都必须确保规则或遵循规则，或者可能对其调用者施加类似的规则，等等。显式内存管理增加了接口的复杂性，接口越复杂，越容易导致内存错误 - 而在C中，内存错误会导致程序崩溃。
不幸的是，有时必须有一个对象（a）必须在运行时分配，（b）必须比分配它的函数的激活寿命更长。在这种情况下，即使看起来这可能是一个坏主意，我们别无选择，只能进行分配，使界面复杂化，并要求调用者正确管理对象。
（其中一个更简单的情况是在运行时分配一个对象但允许永久存在。但是你必须限制这些对象的数量，否则你的空间就会用完。）
在函数中分配内存并不一定是个坏主意。你必须确保适当地清理它。
问题是，一旦离开功能范围，您可能会失去这样做的能力。
小心你的设计。每次都免费匹配malloc，你不会有内存泄漏。
如果你只是按照自己的风格保持一致，这不是一个坏主意。
一个好的方法是将分配的内存传递给调用者，然后调用者可以在完成后释放它。像这样的东西：
void my_new(char **obj) {
*obj = malloc(somesize);
}
然后从你的函数调用这个：
char *obj;
my_new(&obj);
/* work on obj */
free(obj)
管理内存有一些模式：
记住一致性，否则很容易导致内存泄漏或悬空指针。