On Sun, Jun 9, 2013 at 12:38 PM, René Scharfe
> Am 09.06.2013 04:25, schrieb Felipe Contreras:
>> It doesn't. I thought you already silently agreed that nobody would
>> ever find that leak, as they haven't found the hundreds of leaks that
>> plague Git's code.
> Nah, I explained non-silently that leakage was a design decision for
> short-running commands that allocate memory, use it and exit. Reusing such
> code without freeing allocated memory between runs explicitly turns a "good"
> leak into a "bad" one, as we saw with cherry-pick --stdin.
git cherry-pick for multiple commits is already there, such a leak
would be a bad one, and nobody would find it. Valgrind doesn't know
about your concept of "good" leaks, all that you see is tons of leaks.
> Any more sequences that we need to guard against, or counterexamples?
I don't know.
>> In the meantime, just in case, the only sane thing to do is free the
>> entries rather than leak.
> I consider not plugging a leak which we don't know how to trigger with
> existing code even more sane. Yay, circles! ;-)
There's absolutely no benefits to leaving the potential leak.
> Let's take it step by step: Once the known leak is plugged we can worry
> about the unknown ones. I'll send small patches.
Go ahead. I'm not interested any more.
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