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.
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 |
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 |