Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <2198B9E6-B467-45DB-AE82-F1CF90F483AE@sharp.fm>
References: <75ED2CB5-B12E-4516-BED3-9BD0263282F3@apache.org> <2198B9E6-B467-45DB-AE82-F1CF90F483AE@sharp.fm>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Thu, 19 Jan 2017 13:16:51 -0600
Message-ID: <CACsi252yQ727VKWXcEKdi7K1gnAiOvou18Kpu5-PQFhBd4dz+g@mail.gmail.com>
Subject: Re: clang-analyzer?
To: httpd <dev@httpd.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 19 Jan 2017 19:17:04 -0000

On Mon, Jan 9, 2017 at 3:48 AM, Graham Leggett <minfrin@sharp.fm> wrote:
> On 08 Jan 2017, at 4:45 AM, Leif Hedstrom <zwoop@apache.org> wrote:
>
>> I ran clang-analyzer against the HTTPD master branch, and it found 126 i=
ssues. Many of these are benign, but I was curious if the community has any=
 thoughts on this? With another project, I=E2=80=99ve found that keep stati=
c code analysis to zero issues can really help finding new, serious issues =
(basically, we put the tree in failed state if there=E2=80=99s a new static=
 code analysis issue).
>>
>> The issues are all over the source code, in core and mod_=E2=80=99s alik=
e. It=E2=80=99d be pretty tedious to file individual tickets for each of th=
em, so curious if there=E2=80=99s any interest in cleaning this up to start=
 with a clean state? It=E2=80=99d then be easy to add clang-analyzer to the=
 release process for example.
>
> Adding clang-analyzer to a make target (not a default part of the build) =
would be a good step, it would make it easy for anyone to run it if they ha=
d it available.
>
> The most effective contributions would be patches to fix each one. From e=
xperience it is difficult to fix these sort of things without the ability t=
o rerun the analyser to ensure the issue is gone, and every now and again i=
ssues uncover things that may take some time to fix. Agreed that getting th=
ese things to zero would be a good thing to have.

Fixing those that are bugs is a no-brainer.

Getting these to zero, let's say the 80% that don't represent bugs...
is a challenge.

1. We fix on trunk. Backports of later bug fixes are harder to apply.

2. We fix on trunk and backport to 2.4. Simplifies any later backports.
   But this also introduces unnecessary regressions.

My personal preference...

3. We create a patch to trunk for these issues (in a working branch
   would seem most straightforward, but a git clone and fork could
   also hold this work in progress.) Apply only once the beta to our
   next major.minor appears to be acceptable for GA, and in one final
   beta cycle, introduce these no-op changes, including whatever
   formatting and whitespace cleanup is desired by the group.

Third option also makes backports to the legacy branch harder to
apply, but at this point, fewer backports would be expected, so the
net merge time and hassle should be less than the first option of
committing no-op fixes to trunk as they are encountered.