Почему GCC не пытается проверить утечку памяти?

Question

Хотя я редко использую 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 предупреждения не генерировались.Хотя я могу понять, почему компилятор не может дать идеальный ответ, потому что вы имеете дело с кучей памяти и управляете ею во время выполнения, почему компилятор не пытается предупредить о возможной утечке памяти?

Некоторые из моих мыслей о том, почему:

1. Компилятор может не иметь идеального способа сообщить, когда освобождается память.Например, если один из этих указателей был передан в функцию и освобожден из этой функции, компилятор может не сказать этого.
2. Если другой поток становится владельцем памяти, компилятор не будетесть какой-нибудь способ сказать, что кто-то еще может освободить память.

Answer 1

Случаи, которые не могут быть обнаружены с помощью статического анализа (не говоря уже о тривиальном статическом анализе), значительно превосходят те, которые могут. Авторы компилятора, по-видимому, решили, что преимущества добавления этой дополнительной сложности в GCC перевесили затраты.

Answer 2

Это немного сложнее, чем подсчет вызовов free и malloc. Представьте себе библиотеку, в которой некоторые библиотечные функции предполагают, что библиотека вызывает malloc, но предполагают, что пользователь библиотеки вызовет free.