I thought memory leak is when a program or a process keeps on hogging resources little at a time over long period of time. Eventually, that leading to system failure or program crash not when for instance...
I would call any memory that is not explicitly returned a memory leak.
A once off leak is still a leak.
A "harmless" leak, is still a leak.
A leak "repaired" by your OS (free on exit) is still a leak.
If you allocate one instance of TFoo (and one only), and you need it throughout the entire lifetime of your app, you should still return it.
Even if a once off memory leak may not harm you. (That is, if the OS reclaims the mem on app exit).
--------------------
In any case: leaktrc (and maybe other tools too) can not tell the difference between a memory leak that is intended, and a leak that may run you out of memory.
That means, if you choose to ignore some of them, then it becomes harder to check for the others.
---------------------
As I said valgrind may have more options. I dont know if it has an ignore list or not. But even if it has, you have to maintain it. And as your app changes, the same leak may need a diff entry in such a list (as the leak "moves"). So even with an ignore list (if there is one) it will still be extra work to do the ignoring...