Re: Clang 3.3 Analyzer Results

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Clang 3.3 Analyzer Results
Дата
Msg-id 18795.1384304391@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Clang 3.3 Analyzer Results  (Jeffrey Walton <noloader@gmail.com>)
Ответы Re: Clang 3.3 Analyzer Results  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers
Jeffrey Walton <noloader@gmail.com> writes:
> On Tue, Nov 12, 2013 at 7:11 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> We have marked a large number of memory leak reports by Coverity in
>> initdb and other short-lived programs as false positive, on the grounds
>> that there's no point in freeing memory in a program that's about to
>> terminate anyway.  I'm not saying I agree necessarily with that POV, but
>> if we take that stance then there's similarly no point in fixing this
>> leak in the regression test code, is there?

> Ah, OK. So I would disagree here.
> Test code has to meet the same standards as production code.

No, this isn't about test code vs production, it's about not bothering
to free memory explicitly when a program is about to terminate.  Alvaro
is suggesting that the proposed addition to pg_regress.c is just a waste
of cycles.  IMO it's not that big a deal either way in this case, since
it's just one line of code that isn't going to take too long.  However,
I would push back pretty darn hard if you suggested that, say, the
server needed to explicitly free everything it'd allocated before
terminating --- the amount of bookkeeping needed for that would be
ginormous, and it would be 100% pointless.

From a testing standpoint, that means we need a way to explain to
any analysis code that we don't care about the fact that specific
allocations will still be there at termination.  This isn't all that
much different from suppressing other types of false positive, of
course.  As Alvaro and a couple of other people have mentioned, we've
gone to some effort to identify and mark false positives with Coverity.
I'm not convinced yet that clang's tools are mature enough to justify
putting in similar effort with it.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: nested hstore patch
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]