Coverity (and scan-build) are quite useful to spot mistakes even if their false-positive ratio tend to be quite high. Even the false-positives are usually interesting since the spot code unnecessarily convoluted. The code should be as simple as possible but not simpler.
The basic idea behind those tools is to try to follow the code-paths while compiling them and spot what could go wrong (e.g. you are feeding a NULL to a function that would deference it).
The problems with this approach are usually two: false positive due to the limited scope of the analyzer and false negatives due shadowing.
Coverity might assume certain inputs are valid even if they are made impossible by some initial checks up in the codeflow.
In those case you should spend enough time to make sure Coverity is not right and those faulty inputs aren’t slipping somewhere. NEVER try to just add some checks to the code pointed as first move, you might either hide issues (e.g. if Coverity complains about uninitialized variable do not just initialize it to nothing, check why it happens and if the logic behind is wrong).
Ever increasing issue count
While fixing issues using those tools you might notice to your surprise that every time you fix something, something new appears out of thin air.
This is not magic but simply that the static analyzers usually keep some limit on how deep they go depending on the issues already present and how much time had been spent already.
That surprise had been fun since apparently some of the time limit is per compilation unit so splitting large files in smaller chunks gets us more results (while speeding up the building process thanks to better parallelism).
Usually fixing some high-impact issue gets us 3 or 5 new small impact issues.
I like solving puzzles so I do not mind having more fun, sadly I did not have much spare time to play this game lately.
Merge ALL the FIXES
So far about 100+ patches got piled up over the past weeks and now they are sent in small batches to ease the work of review. (I have something brewing to make reviewing simpler, as you might know)
During the review what probably about 1/10 of the patches will be rejected and the relative coverity report updated with enough information to explain why it is a false positive or the dangerous or strange behaviour pointed is intentional.