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

From Peter Geoghegan
Subject Re: Clang 3.3 Analyzer Results
Date
Msg-id CAM3SWZRH=-+bjHRQOqdCEqCvU6B5dzXfQZUaDi1nrW0KEgF6Xw@mail.gmail.com
Whole thread Raw
In response to Re: Clang 3.3 Analyzer Results  (Kevin Grittner <kgrittn@ymail.com>)
Responses Re: Clang 3.3 Analyzer Results  (Jeffrey Walton <noloader@gmail.com>)
Re: Clang 3.3 Analyzer Results  (Kevin Grittner <kgrittn@ymail.com>)
Re: Clang 3.3 Analyzer Results  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Mon, Nov 11, 2013 at 2:18 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> I'm currently capturing a text version of all the warnings from
> this.  Will gzip and post when it finishes.  It's generating a lot
> of warnings; I have no idea how many are PostgreSQL problems and
> how many are false positives; will just post the whole set FWIW.  I
> am using the 3.4 development nightly snapshot with these commands:

When I tried out scan-build a while ago, the results were kind of
disappointing - there were lots of false positives. Clearly the tool
was inferior to Coverity at that time. I'd be interested to see if
there has been much improvement since.

One thing I noticed at the time was that the tool didn't have any
gumption about elog() and control flow, even though IIRC at that time
we had the abort() trick (see commit
71450d7fd6c7cf7b3e38ac56e363bff6a681973c). I seem to also recall
Coverity correctly handling that, although perhaps I'm unfairly
crediting them with taking advantage of the abort() trick because of
the state of Postgres when I tried each of those two tools - it might
be that scan-build *would* have taken advantage of that at the time,
if only the trick was there.


-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: pg_dump and pg_dumpall in real life
Next
From: Jeffrey Walton
Date:
Subject: Re: Clang 3.3 Analyzer Results