[Bf-committers] PVS-Studio Static Analysis

Jason Wilkins jason.a.wilkins at gmail.com
Thu Apr 26 01:16:03 CEST 2012


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.

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


More information about the Bf-committers mailing list