为什么 GCC 不尝试内存泄漏检查？答案

【问题标题】：Why does GCC not attempt memory leak checking?为什么 GCC 不尝试内存泄漏检查？
【发布时间】：2012-01-16 10:30:41
【问题描述】：

虽然我很少再使用 C，但我在思考一个规则，我总是被告知“如果你调用 malloc()（或 new），你必须调用 free()（或 delete）”。它让我想知道 GCC（或其他 C 编译器）是否会尝试执行任何类型的内存并警告用户潜在的问题。我从来没有听说过，所以我怀疑不是这样，但我想知道。

这是我使用的示例：

#include <stdlib.h>

int main() {
  int* first = malloc(sizeof(int) *  10);
  int* second = malloc(sizeof(int) * 10);

  int i = 0;
  for (; i < 10; i++) {
    first[i] = i * 2;
    second[i] = i * 10;
  }

  free(first);  /* Forgot to free second */
  return 0;
}

当使用gcc -Wall free_test.c 编译时，不会产生任何警告。虽然我可以理解为什么编译器无法提供完美的答案，因为您正在处理堆内存并在运行时对其进行管理，但为什么编译器似乎没有尝试提供可能存在内存泄漏的警告？

我的一些想法包括：

编译器可能没有完美的方式来判断何时释放内存。例如，如果其中一个指针被传递给函数并从函数中释放，编译器可能无法判断。
如果另一个线程拥有内存的所有权，编译器将无法判断其他人可能正在释放内存。

【问题讨论】：

问题是这是一个运行时问题，编译器无法检测到内存泄漏之类的东西。例如，仅仅因为我没有立即释放指针并不意味着其他一些代码块在很久以后也不会释放它。
不，我想不是。这只是我很好奇的事情（因为我想这是可能的）抛出一个表明可能存在问题的警告。
即使是像 C# 编译器这样的现代编译器也无法检查这一点。他们依靠像垃圾收集器这样的运行时构造来做到这一点。

标签： c memory-management gcc memory-leaks

【解决方案1】：

无法通过静态分析（更不用说通过微不足道的静态分析）检测到的案例远远多于可以检测到的案例。编译器的作者大概认为向 GCC 添加这种额外的复杂性所带来的好处超过了成本。

【讨论】：

【解决方案2】：

这比计算free 和malloc 调用要复杂一些。想象一个库，其中一些库函数假定库调用malloc，但假定库的用户将调用free。

【讨论】：