Não ter leak de memória é bem fácil, na real

{INFO}: Esse post não tem relação nenhuma com o canal Bem fácil, na real, só achei que o título combinava 🙂

Se você coda em uma linguagem com gerenciamento manual de memória já deve ter se deparado com um double free ou com o famoso memory leak.

E por mais que existam Arenas, smart pointers e Garbage Collectors muita gente ainda falha em criar um programa sem vazamentos.

A solução é muito simples e provavelmente uma frase que você ouviu da sua mãe quando era criança "Coloque tudo de volta em seu devido lugar", mais especificadamente a parte "seu devido lugar", ou seja, aloque e desaloque memória em seu devido lugar.

int main()
{
    char *ptr = malloc(100 * sizeof(char));
    size_t addr = (size_t)ptr;

    for (int i = 0; i < sizeof("Hello, World!\n"); ++i, ++ptr)
        *ptr = "Hello, World!\n"[i];
    *ptr = '\0';

    ptr = (char*)addr;
    printf(ptr);

    free(ptr);
    return 0;
}

Nesse exemplo a memória alocada para ptr é desalocada no mesmo local que ptr.

typedef struct {
    char *ptr;
} Object;

Object objectInit(void)
{
    Object o;
    o.ptr = malloc(100 * sizeof(char));
    return o;
}

int main()
{
    Object obj = objectInit();
    size_t addr = (size_t)obj.ptr;

    for (int i = 0; i < sizeof("Hello, World!\n"); ++i, ++obj.ptr)
        *(obj.ptr) = "Hello, World!\n"[i];
    *(obj.ptr) = '\0';

    obj.ptr = (char*)addr;
    printf(obj.ptr);

    free(obj.ptr);
    return 0;
}

Já nesse outro a alocação não pode ser liberada na mesma função, então vamos liberar na função mais próxima dela, ou seja, no local onde a função alocadora foi chamada.

E isso é gerenciamento de memória for dummies... foi tão difícil assim?... Ah, sim, faltou falar de "e se a alocação falhar". Bom, se a alocação falhar, a gente só libera o que já foi alocado.

Fique avisado que o código que será visto a seguir é o maior pecado da programação, devido a algo tão proibido que somente os maiores programadores são permitidos de usar.

typedef struct {
    char *ptr;
    // ... finge que tem outros 100 atributos aqui.
} Object;

Object* objectNew(void)
{
    Object *o = NULL;

    o = calloc(1, sizeof(Object));
    if (!o)
        return NULL;

    o->ptr = malloc(100 * sizeof(char));
    if (!o->ptr)
        goto error_return;
    // ... inicializa os atributos

    return o;
error_return:
    // ... libera os atributos
    if (o->ptr) free(o.ptr);
    free(o);
    return NULL;
}

void objectDelete(Object *o)
{
    if (!o)
        return;
    // ... libera os atributos
    if (o->ptr) free(o->ptr);
}

void objectDelete2(Object **o)
{
    Object *temp = NULL;

    if (!o || !(*o))
        return;
    temp = *o;
    // ...
    if (temp->ptr) free(temp->ptr);
    free(*o);
    *o = NULL;
}

Object* objectDelete3(Object *o)
{
    if (!o)
        return o;
    // ...
    if (o->ptr) free(o->ptr);
    free(o);
    return NULL;
}

int main()
{
    Object *obj = objectNew();
    Object *obj2 = objectNew();
    Object *obj3 = objectNew();
    // ...
    objectDelete(obj);
    free(obj);
    // delete considera que o objeto principal/container é responsabilidade do usuário
    objectDelete2(&obj2);
    // delete2 considera já definir o objeto principal/container para nulo dentro da função.
    obj3 = objectDelete3(obj3);
    // delete3 prefere deixa o usuário decidir se o objeto vai ser definido para nulo.
    // um delete4 poderia ter flags que decidem se o objeto vai ser liberado ou não e se vai definido para nulo ou não.
    return 0;
}

Nesse último exemplo temos uma função que aloca um objeto e utiliza o temido GOTO em caso de erro, porque imagina o trabalho de ter que escrever cada if para cada possível erro no meio do código, é muito mais fácil pular para uma "zona de erro" e lidar com a liberação de recursos que estavam sendo utilizados.

Além da função que aloca o objeto, temos também funções que liberam os recursos após eles serem utilizados, cada uma com sua curiosa implementação um pouco diferente.

Bom, então é isso, se você simplesmente seguir essa regra é 99,99999% de certeza que você não vai ter um único leak de memória (os 0,00001% são de leaks internos de funções de bibliotecas).

Comentem casos que não foram abordados, discordâncias da minha opinião que podemos classificar minimamente como polêmica e é claro, compartilhe para seus amigos.