[Bf-committers] PVS-Studio Static Analysis

[Campbell Barton]

On Thu, Apr 26, 2012 at 9:16 AM, Jason Wilkins
<jason.a.wilkins at gmail.com> wrote:
> p.s., not that I'm against annotating false positives in source code
> (or better yet, rewriting in a less suspicious manner).  I do not
> believe in forcing programmers to do things.  However, if we ever
> wanted to require that Blender ship with zero warning flags from these
> kinds of tools there is going to have to be some kind of centralized
> way to customize the warnings so that all developers can work against
> the same template.
>
> This is why I like Sonar for Java, you can set up a central web server
> that tracks all the warnings and everybody can check against that.
> But it does not do exactly what I suggested (let you mark
> false-positives in the database).  However, it is also a more sensible
> tool because I've never had it flag something I either did not really
> have to fix or was not actually a good suggestion to improve the code.
>  C/C++ tools will probably never be that good.
>
> On top of that, I compiled Blender with MSVC 2008 warning level 4 and
> got 14,000 warnings.  It would be nice to have a tool that could
> actually automatically track those.  As it is, it seems like a
> nightmare to even try to see if there is anything useful in those 14k
> warnings.

My first reaction when building blender in MSVC was - "how can anyone
use this!" - the output flooded with warnings almost all being near
useless, now IIRC the warning level is set lower now but its still not
great.

A while back I tried to get cmake/gcc building with zero warnings and
we are close to being there (some are really hard to get rid of
because of differences in external headers across versions).

The way I did this was to set -Wall -Wextra, then disable warnings one
by one which are things blender does often and are not useful to be
warned about on every build. eg: -Wno-unknown-pragmas,
-Wno-char-subscripts

Another thing that was needed was a way to remove even more warnings
for 3rd party libs in extern/ since we dont maintain that code making
small edits only get lost when updating the libs.
For this there is a CMake macro "remove_strict_flags()", defined in
./build_files/cmake/macros.cmake to remove -Wunused-parameter,
-Wstrict-prototypes for example.

Locally I use -Werror so if someone commits error causing code into
blender It won't build for me, but dont enable this by default since
it would get annoying for non developers to build.


Theres nothing stopping someone making use of this same methods for
MSVC so we get useful warning output.
14,000 warnings sound bad but so many are harmless they just need to
be suppressed.

> On Wed, Apr 25, 2012 at 5:57 PM, Jason Wilkins
> <jason.a.wilkins at gmail.com> wrote:
>> If the source line changes then diff isn't a good enough tool.  What
>> is needed is a that these programs need to maintain a database that
>> keeps a signature of each problem that is basically an AST of the area
>> affected and is independent of source line and whitespace changes.
>> Then you could annotate this database with information about false
>> positives instead of your source.  Such a database might even be able
>> to keep new false positives from appearing if you duplicate the
>> problem exactly in a different source file.
>>
>> On Wed, Apr 25, 2012 at 11:13 AM, Mr Rasmus Lerchedahl Petersen
>> <rusmus at eecs.qmul.ac.uk> wrote:
>>>> Running a second time gives you only the false positives again.
>>>> If some new bug is added to the source you still needed to read over
>>>> the false positives (unless your memory is really good).
>>>>
>>>> long term we need to have a way to notify us when new errors are added.
>>> Sounds like a job for diff?
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell