----- Taras Glek <[email protected]> wrote: > Ok. Thanks for the examples. Can you assign the sixgill bug to yourself?
Hi, I added an nsDebug.h patch to bug 541220. How do I assign the bug to myself? > I think the way we will land this is by adding another build option to > Mozilla(similar to --with-static-checking flag). This might not be necessary. The process I've been using doesn't require any modifications to the mozilla build, but works by wrapping that build in a script which does two things: 1. Forks a manager process which collects and collates the plugin's results into some output databases. 2. Modifies PATH to intercept calls to gcc/g++/etc. and insert the appropriate xgill plugin arguments. The plugin communicates with the manager via a socket. > Once we land this we will need to land annotations to fix the false > positives. These annotations would have to broken up into patches with > module-granularity. Generally that is done by filing individual bugs for > each component. Should set the bugs as depedent on 541220. Hopefully, > module-maintaines will help out. Are these component-level bugs mainly for dependency tracking, i.e. would it be possible to commit a patch that adds just a few annotations? It would be great to have a low barrier to adding annotations to the source, since they don't change the behavior of the code at all. One thing that could help here is having a web interface for annotations so that they can be added without modifying the source. I had a prototype for this working last month and one of my TODO items is to get this working for real, so that any annotation you can add directly to the source can also be added over the web. > What would it take to be airtight? Is that even realistic? Yes, this is realistic, and is a main goal of this project. I want to be doing verification, but the analysis needs to be practical first and foremost (these have historically been mutually exclusive). There's some on this in the slides, and will be a lot more once the documentation is done. Basically though, there are two holes regarding integer overflow and clobbered null terminators that should be fixed by writing separate analyses (using the same framework), and several minor holes that need to be fixed directly (mainly for interprocedural aliasing and call modsets). Brian _______________________________________________ dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
