Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
