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

From Jeffrey Walton
Subject Re: Clang 3.3 Analyzer Results
Date
Msg-id CAH8yC8k9zyx7ts=jRhZ46WNfARnUZSWdR4nVR+C1wqYLOEdXbw@mail.gmail.com
Whole thread Raw
In response to Re: Clang 3.3 Analyzer Results  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Clang 3.3 Analyzer Results  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Nov 12, 2013 at 7:11 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Kevin Grittner escribió:
>
>> These both seemed legitimate to me.  Patch attached.  Any
>> objections to applying it?  I realize the memory leak is a tiny one
>> in the regression testing code, so it could never amount to enough
>> to matter; but it seems worth fixing just to avoid noise in code
>> analyzers.
>
> 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.
Otherwise, it could create spurious noise that could mask real
findings :)

It kind of begs a few questions. How is an user, integrator or auditor
supposed to know ....

* devs write 'real code' in the libraries and programs, as opposed to
'non-real code' in their test suite
* what the devs have deemed 'not a good expenditure of resources'?

Anyway, its just my philosophy. I know many projects share the
opposing point of view.

Jeff



pgsql-hackers by date:

Previous
From: Jeffrey Walton
Date:
Subject: Re: Clang 3.3 Analyzer Results
Next
From: Andrew Dunstan
Date:
Subject: Re: nested hstore patch