[PATCH 0/2] UNLEAK style fixes

Although we introduced UNLEAK() long ago, I don't know that anybody has really made a concerted effort to annotate enough variables to make running a leak-checker useful. So I haven't paid too much attention to its use.

But a few people have added some annotations, and I think some of them aren't great examples. So I decided to clean them up. This by definition has no impact on regular builds (since UNLEAK is a noop there), but even in leak-checking builds should give no behavior change.

Another category that I was tempted to change is when variables _could_ be freed, but we just don't bother to do so. E.g., at the end of bugreport.c, we have:

  UNLEAK(buffer);
  UNLEAK(report_path);
  return !!launch_editor(report_path.buf, NULL, NULL);

Using UNLEAK(report_path) makes sense; we can't free it because we're passing it to a function that runs until program end. But we _could_ free "buffer" here, which isn't otherwise used again (i.e., that could be strbuf_release() instead of UNLEAK).

But that does have a run-time cost (we'd actually free the memory, even though we could just exit and let the OS handle it). My guess is that it's not a measurable cost, and the code might be cleaner to actually clean up instead of sprinkling more UNLEAKs around. But until we're actually pushing forward with a real effort to get a leak-checker running clean, I don't see much point in doing one or the other.

(As a side note, if we want to declare UNLEAK() a failure because nobody cares enough to really use it, I'm OK with that, too).

  [1/2]: stop calling UNLEAK() before die()
  [2/2]: ls-remote: simplify UNLEAK() usage

 bugreport.c         | 4 +---
 builtin/ls-remote.c | 8 +++-----
 midx.c              | 8 ++------
 3 files changed, 6 insertions(+), 14 deletions(-)

-Peff