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.
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.