On Tue, May 17, 2016 at 11:16 AM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@google.com> writes: > >> So as a developer I wish we would close all leaks that are non-concerning. > > Valgrind suppression (and if you use other tools, suppression for > them) sounds like the way to go, I would think. > > Reducing false positive is a good goal; it helps to highlight the > real problems. But we need to find a way to do so without hurting > the use by the end users by making them pay the unnecessary cost to > free() at the end and by cluttering the code with #ifdefs that makes > it easier to introduce subtle bugs.
That's why I think the `optional_free` is a good thing as it doesn't clutter the code? > >> David writes: >>> AFAIK, nothing in the "definitely lost" category is fixed by your rev-parse >>> patch. >>> >>> I don't think we care that much about "still reachable" memory -- I only >>> care about lost memory. I could imagine, I guess, something that happens >>> to save a pointer to a bunch of memory that should be freed, but I don't >>> think that's the common case. >> >> As said above I'd want them to be fixed for me as a developer for >> better automated tooling and detection. (The alternative to fix the automated >> tooling is a no-no for me ;) > > Does the word "no-no" mean what you seem to think it means? It > sounds as if you are saying "fixing tools to reduce false positives > is fundamentally wrong, I refuse to go in that direction". > I just mean, that I have not enough time to do that, so I won't. I know however how to send patches to this list. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
