¿Por qué preocuparse por la pérdida de memoria?

Échale un vistazo a la lista de errores de Mozilla y una cosa es clara: el nuevo código que entra a Mozilla no es (o no ha sido) verificado suficientemente por pérdida de memoria y problemas de acceso.

Las pérdidas de memoria son malas por varias razones:

Se comerá el área de intercambio lentamente. A la larga tu programa, o hasta tu máquina sucumbirán.
Nadie quiere que su programa o biblioteca adquiera la reputación de ser una porquería sólo porque uno ha sido un vago. Déjaselo a las personas en Redmond.
Ocultan el mal uso de la memoria. Si olvidas liberar la memoria, no hay forma de atrapar las lecturas y escrituras a esos trozos de memoria. Si, posteriormente, reparas la pérdida, una parte completamente distinta del programa podría fallar.
Cuando se usan verificadores automáticos de memoria, nadie quiere ver 600 problemas, de los cuales 500 se encuentran en las bibliotecas de soporte. Lo que deseas saber es que estaba todo limpio antes que comenzara el caos, y por lo tanto, esos problemas te corresponde a ti arreglarlos.
Este es uno de los problemas de Mozilla actualmente: pierde memoria sin parar así que ¿cómo vas a saber si has contribuido al problema?

Algunos consejos contra la pérdida de memoria.

Usa «const» donde sea posible (para punteros obviamente).
Si un argumento es «const», entonces indudablemente la función llamada no liberará la memoria por ti.
Si el tipo de resultado de una función es «const», entonces claramente no eres responsable por liberarlo. Probablemente lo será para un resultado distinto de «const» (que no sea un entero o algo similar).
Fíjate en que, desafortunadamente, esto no funciona muy bien con los objetos que cuentan referencias. Funciona bien con cadenas.
Dado que C usa llamadas por valor, no tiene sentido aplicar «const» a tipos int, double y similares.
Documenta las responsabilidades.
- Si una función toma la propiedad de un objeto/referencia, sé explícito acerca de ello.
- Indica siempre si el que llama a la función debiera liberar/desreferenciar los resultados.
- Documenta cómo entregar la memoria: unref, free, g_free, ...
Se cuidadoso cuando uses copiar-y-pegar.
El proceso de cortado y pegado no mejora el código, al contrario de lo que creen muchos programadores. Primero, mira el código y si intenta producir muchas copias, quizás necesite una función ayudante o nexo.
Libera todo antes de salir.
Esto lleva tiempo, así que quizás debieras hacerlo sólo dentro de una condición.
El motivo de este consejo es que los verificadores de memoria toman tiempo en determinar entre una pérdida que tu conoces y no te preocupan, y las otras pérdidas.
No dejes punteros sueltos en tus estructuras de datos.
Asigna NULL o (void *)0xdeadbeef para los miembros liberados a menos que vayas a liberar la estructura a la que pertenecen.
Los punteros sueltos tienen la mala tendencia a ocultar pérdidas de memoria.
Ejecuta el nuevo código en un ciclo 1 millón de veces.
Si pierdes memoria, lo sabrás — sólo sigue al proceso con top en otra ventana. Podrías querer especificar a top el PID del proceso con la opción -p.
Repáralo ahora, no después.
No escribas una porquería de código; más temprano que tarde te pesará.