Re: Clang 3.3 Analyzer Results - Mailing list pgsql-hackers

From Jeffrey Walton
Subject Re: Clang 3.3 Analyzer Results
Date
Msg-id CAH8yC8knrbE2r=g=oEri739SQnuMnZjWhoY09-Pz40Nu+8pWXw@mail.gmail.com
Whole thread Raw
In response to Re: Clang 3.3 Analyzer Results  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Clang 3.3 Analyzer Results  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ...
>
> One thought for the Clang people is that most of the reports such as "null
> pointer dereference" presumably mean "I think I see an execution path
> whereby we could get here with a null pointer".  If so, it'd be awfully
> helpful if the complaint included some description of what that path is.
> I think Coverity does that, or at least I've seen output from some tool
> that does it.
Clang can be trained with asserts.

If you are certain that a parameter cannot be NULL, then pass the
knowledge onto Clang: assert(param != NULL). Clang will stop analyzing
that path for NULL-ness.

Or, you could check it for NULL and fail the function if the param is
NULL. If its a spurious test, then the optimizer will remove it.

Jeff



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: GIN bugs in master branch
Next
From: Andres Freund
Date:
Subject: Re: Clang 3.3 Analyzer Results