当第三方C函数返回指针时,您应该自己释放它吗?

真的没有一个标准规则。有些函数需要您传入一个指针,它们将数据填充到该空间中(例如。, sprintf <time.h> setvbuf ).

希望 文档告诉您需要释放哪些指针。除非文档告诉您,否则通常不应该尝试释放它返回的指针。除非您要传递缓冲区的地址以供它使用,或者它指定您需要释放内存,否则通常应该假设它使用的是静态数据区。这意味着(除其他外)你应该假设 可由对同一例程的任何后续调用更改。如果您正在编写多线程代码,通常应该假设函数

你要看文件,没有别的办法。我的手册页 inet_ntoa 内容如下:

因此,在这种情况下,不能尝试释放返回的指针。

没有标准规则。理想情况下,标准库函数(如inetúntoa)会附带一个man 描述“参与规则”的页面,即函数的接口-预期参数、成功和错误时的返回值以及处理分配内存的语义。

从inetúntoa的手册页:

Internet主机地址,以 网络字节顺序,以字符串形式输入 字符串以静态方式返回 分配的缓冲区 呼叫将覆盖。

至少在我的机器上(MacOSX10.6)手册页的最后一句话 BUGS 是:

inet\u ntoa()返回的字符串驻留在静态内存区域中。

inet_ntoa 是 不在POSIX中

返回指针到已分配内存的标准函数的数量实际上相当少,大多数这样做的函数都提供了一个特殊的补充函数,您需要使用它来释放内存(例如, fopen fclose , getaddrinfo freeaddrinfo ,或 regcomp regfree ). 只是打电话 free 返回的指针上的错误将非常糟糕;充其量会导致严重的内存泄漏,最坏的情况可能会导致意外的崩溃(例如,如果库将分配给它的对象保留在一个链表中)。

无论函数是系统库还是第三方库的一部分,它都应该记录它返回的任何指针的预期用法(以及是否/如何释放它们)。对于标准函数,最好的参考是 POSIX itself . 您还可以检查特定系统的手册页。如果代码是第三方库的一部分,那么它应该附带文档(可能在手册页、头文件或关于库用法的综合文档中)。一个编写良好的库将提供特殊的函数来释放它分配的对象,从而避免对使用库的代码(当前)实现的方式引入依赖。

伊内图安托亚 ,他们是 或者他们 可以返回指向内部静态缓冲区的指针,该缓冲区可能会被后续调用覆盖 到函数。包括我在内的许多人都认为,在现代代码中根本不应该使用这样的函数。