https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #9 from frankhb1989 at gmail dot com --- (In reply to Andrew Pinski from comment #8) > (In reply to frankhb1989 from comment #7) > > This is definitely a leak from the view of libc. Why is the status INVALID > > instead of WONTFIX? > > It is still reachable. Since it is reachable, a pointer at deconstructor > time could use it. This pool is used to low memory situations. And can be > used even near exit. There is no leak; a leak means it is no longer > reachable. > Most programs will not free some of their memory at the end of their program > anyways; they would just call exit. Following your narrow definition of "leak", it implies that any system using GC could never leak. That's absurd. 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. If that resource is not needed and there is no other way to transfer the ownership, it is leaked. 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. (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.
