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.wilk...@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 > <rus...@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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers