Re: [RFC PATCH 03/15] reftable: don't memset() a NULL from failed malloc()

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>> Future analyzer reports are likely of the same quality as the current
>> ones.  If the goal is to shush them then we should just not use the
>> analyzer.  If reports contain a helpful signal, e.g. pointing to a real
>> bug or to overly complicated code, then we better address these issues.
>>
>> We can think about automating the analyzer once we have a certain number
>> of commits with improvements that would not have been made without it.
>
> We might decide not to go with -fanalyzer in CI or whatever, but I
> really think that your line of reasoning here is just the wrong way to
> evaluate the cost/benefit of -fanalyzer, a new warning or whatever.

To me, your priorities look much less in line with this project's
than what Rt Réne gave us above.

> The question shouldn't be whether those things in particular were worth
> the effort, but whether the added safety of getting the new diagnostic
> going forward is worth the one-time cost.

Workarounds for false positives are hardly one-time cost.  They have
to stay with us until the -fanalyzer gets corrected, somebody needs
to remember to occasionally check if that happened, and revert the
workaround to bring the code into their more natural form.  What has
been good and readable for human programmers for a long time does
not need to be touched just to work around a false positive bug in a
new tool.

> I find the warning output from -fanalyzer to be *really useful*.

I do not mind if you add -fanalyzer during your build via your own
config.mak file, and you would help them improve the analyzer by
reporting false positive bugs while finding possible bugs in the
code we have (like you did in a few patches in this series) and the
code you are writing.  You are capable enough to keep your own set
of patches to work around their false positive bugs locally.

But if you have to send in 15 patches with more workaround changes
than real fix, then it is premature for us to bear the cost to have
workaround for the tool.

There are folks who use our codebase as a suitably-sized guinea pig
to improve their tool, and we should not make it harder for them to
do so, but our priority is to improve the product of this project.

Come to think of it, adding unnecessary workarounds is a hostile act
to those who are trying to improve -fanalyzer, I guess, too.  They
may want to fix problems in their tool, but workarounds hide them.