Re: Clang 3.3 Analyzer Results

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Clang 3.3 Analyzer Results
Дата
Msg-id CAM3SWZRH=-+bjHRQOqdCEqCvU6B5dzXfQZUaDi1nrW0KEgF6Xw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Clang 3.3 Analyzer Results  (Kevin Grittner <kgrittn@ymail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: pg_dump and pg_dumpall in real life
Следующее
От: Jeffrey Walton
Дата:
Сообщение: Re: Clang 3.3 Analyzer Results