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
