https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to frankhb1989 from comment #9) > Following your narrow definition of "leak", it implies that any system using > GC could never leak. That's absurd. Wikipedia: "a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in such a way that memory which is no longer needed is not released." This memory is still needed up until exit. Google: "a failure in a program to release discarded memory, causing impaired performance or failure." This is not discarded memory, and does not impair performance or cause failure. MSDN: "When an application dynamically allocates memory, and does not free that memory when it is finished using it, that program has a memory leak." The memory is in use right until exit, so the application hasn't finished using it. > A leak of resource may occur when the client (either the code of the > application or the underlying runtime responsible to deal with the allocated > resource) has lost the control of the lifetime of that resource. The runtime hasn't lost control of it. > If that > resource is not needed and there is no other way to transfer the ownership, > it is leaked. It's still needed. > Still reachable memory can be leaked, depends on the > intention. Sometimes the leak detector has no clue to figure out whether the > memory should be still here or not, but we humans have, though it may be > arguable. > > The situation necessitating "exit()" to cleanup almost always meets the > condition of leak above. This is feasible only when the users can rely on > the fact that the hosting environment will cleanup the (already leaked) > resources of that program (likely in some magical ways unrelated to the > program itself). This is not portable in general. We're not talking about arbitrary resources in the general case, we're talking about heap memory in the GNU C++ runtime. That memory is freed on exit. If you want to waffle about it further please take it somewhere else. (And abuse of exit() will > easily cause other problems.) I don't see "most" programs do that seriously > because it is not easy to guarantee the behavior predictable.
