Re: Clang 3.3 Analyzer Results

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, "noloader(at)gmail(dot)com" <noloader(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clang 3.3 Analyzer Results
Date: 2013-11-12 22:19:31
Message-ID: 5282A973.9040105@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 11/12/13, 8:18 AM, Kevin Grittner wrote:
> Here is the summary of what was reported:
>
> All Bugs: 313

> Does anything stand out as something that is particularly worth
> looking into? Does anything here seem worth assuming is completely
> bogus because of the Coverity and Valgrind passes?

I have tracked scan-build for some time, and I'm sure that almost all of
these bugs are false positives at this point.

I have a private branch somewhere that I have badly hacked up (e.g.,
hardcoding enable_assert = 1), which gets that number down to 251
according to my latest notes. That's about the best you can hope for.

Btw., you can also keep score here:
http://pgci.eisentraut.org/jenkins/view/PostgreSQL/job/postgresql_master_scan-build/.
This uses an older version of clang, so the number of bugs is lower,
but the nature of the bugs is also more stupid. I plan to upgrade that
at some point.

It's worth keeping an eye on this, but it's not worth losing sleep over.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Goess 2013-11-12 22:28:50 Re: simple query with radically different plan after 9.0 -> 9.2 upgrade
Previous Message Peter Eisentraut 2013-11-12 22:05:30 Re: Clang 3.3 Analyzer Results

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-11-12 22:24:43 Re: Can we add sample systemd service file to git repo?
Previous Message Simon Riggs 2013-11-12 22:14:00 Re: Fast insertion indexes: why no developments