coverity tips

Caolán McNamara caolanm at redhat.com
Thu Jun 5 03:02:37 PDT 2014


a) MISSING_BREAK

if the missing  break is intentional coverity only warns if there is
content in the case statement and the last line is not a comment, i.e.g

case foo:
case bar:
    ...code...
    break;

doesn't warn

case foo:
    ... code ...
case bar:
    ...code...
    break;

does warn and can be silenced by...

case foo:
    ... code ...
    //a comment, e.g. fall-through
case bar:
    ...code...
    break;

b) multiple copies of an issue

Some of the coverity warnings like uninit_ctor will have an instance
count, e.g. two ctors, both don't init a member and there is *1*
coverity bug with (2) in the count column. I found a pile of fixed bugs
that hadn't disappeared automatically where we had only fixed one of the
instances. Watch out for that when fixing those warnings.

c) UNHANDLED_EXCEPTION

coverity is only looking at what the exception specification is and what
throw statements exist in the method. i.e. its not examining the logic
so...

void bar(bool bThrow) throw (foo)
{
    if (bThrow)
        throw foo();
}

int foo throw()
{
    bar(false);
}

will generate a warning, even though bar is only called with false and
the exception cannot be thrown. Generally I've been reworking those to
keep coverity happy by having two different methods, a throwing one and
a non-throwing one instead of a combined one with a throw/no-throw flag.

C.



More information about the LibreOffice mailing list