New Defects reported by Coverity Scan for LibreOffice
Stephan Bergmann
sbergman at redhat.com
Wed Feb 4 06:53:57 PST 2015
On 02/02/2015 04:28 PM, Lubos Lunak wrote:
> On Monday 02 of February 2015, Stephan Bergmann wrote:
>> My take on it is simple: There /is/ a flaw in the above code, and
>> Coverity /does/ correctly identify it. If the asserted condition cannot
>> legitimately be false at that place, the ?: check is wrong and must go
>> away. If it can, the assert is wrong and must go away (or, depending on
>> context, be replaced with a SAL_WARN_IF, say).
>
> That is indeed the theory, but what is the reality? Can somebody with such a
> monstrous codebase say for sure which case it is for every instance of the
> problem?
Nobody can for all of the codebase. But the author adding an assert in
a specific place hopefully can for that instance.
> If memory serves me well, we shipped a couple of releases that under
> some circumstances had VCL KFileDialog integration hitting asserts on
> improper locking, but release builds still managed to cope with it somehow
> (more often than not, anyway).
There must for sure be war stories providing evidence that "defensive
programming" happened to exhibit desirable behavior on occasion.
> Developer builds should of course fall flat on their face in such cases, but
> in practice it's probably better to value end product stability more than
> practically insignificant warnings from a tool.
That's probably where we are of different opinion, that IMO
non-accidental stability can only arise from rigorousness.
More information about the LibreOffice
mailing list