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