[Bf-committers] PVS-Studio Static Analysis

trouble daemon troubledaemon at gmail.com
Thu Apr 26 04:07:26 CEST 2012


Interesting problem you have here. While I don't understand all the
errors themselves per se, I did take a look at the root web page and a
few samples of reports, along with a glimpse at the html it generated.

My initial thought would be some sort of regex like parser that would
be very similar in theory to the perl "swatch" script, or the
logwatch. To summarize the aspects of these that would relate to this:
swatch lets you setup regex rules to match or ignore entries in any
text file, and can vary the color of the output, ignore it, or perform
some action on a match. While logwatch is similar, it basically has a
list of ignore rules/regex, and has formatting information for all the
different syslog (and friends) log formats that it can parse out the
junk (like timestamps and pid's).

I figure that if someone felt like spending an evening, they could
probably take the 2 key concepts (regex, and ignore rules per file
and/or error) from these two programs and toss them into an html
scraper script, you could probably get something that could alert you
to just the stuff that has changed. For example, looking at a few
different reports, I noticed a trend of the same file to have the same
error on the same line number. Clearly in such a case, this output
should be placed on the ignore list (well, assuming you choose to
ignore it), and only report on changes where there is a new "primary
key" of sorts, constructed from the uniqueness of the filename, error
type and line number.

The big problem I see with this, would be maintaining the script in
the event that the html of the clang reports changes. This is actually
the type of problem that I ran into when making the blender filesize
chart, namely that over time, the conventions used to name files and
indicate features was different per arch, release and feature set,
thus making it near impossible to script or automate anything without
hand verification.

I suppose the question is, how important would something like this be,
who will write it, how will it be written (perl+dbm, python+sqlite,
etc etc etc), who will maintain it, who will use and benefit from it.
Tbh, it sounds like a can of worms :)

Anyways, felt like chiming in, later guys o/



troubled

On Wed, Apr 25, 2012 at 9:36 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> While its probably possible to setup some `good enough` solution using
> diff, I tend to agree with Jason - that you need something more
> comprehensive so some minor edits to a file doesn't give you a lot of
> changes to the diff to read through that are in fact only line number
> change or re-ordered functions.
>
> Even though you could probably skim-read the diff and tell new
> additions from line-number offsets - blenders is changing fast enough
> that doing this every day would become a time waster IMHO.
>
> Another issue with diff, clang outputs HTML or PList (some apple xml?)
> - so diffing this output needs someone to work on a tool for that
> specifically.
>
> Checking if number of reports changed was OK until clang started
> crashing in some of our source code, so now it gives different bug
> count every run.
> http://clang.blenderheads.org/trunk/
>
> (yes, I realize some bug could be added and another removed between
> revisions - so its not foolproof).
>
>
> On Thu, Apr 26, 2012 at 8:57 AM, 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
> _______________________________________________
> 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