Praveen, Some static analysis tools indeed run without forcing things to parse correctly. GCC actually works somewhat like you want. Debug gcc error handling and try removing whatever makes it abort. There is a chance you might get far enough along for your needs. However, when there are errors in the source, gcc starts inserting funny error AST nodes which Dehydra doesn't handle.
I'd recommend fixing up your source to compile. C++ in particular doesn't lend itself to making sense when templates don't instantiate correctly. I'm not aware of any static analysis tools that work with ambiguous C++ ASTs. If you are really intent on dealing with broken code, you might have some luck with basing your analyses on the Elsa parser. The GLR parser might be handy here, however parser customization will be required. See our version of Elsa at http://wiki.mozilla.org/Pork Taras Praveen Bhaniramka wrote: > In this case, the compiler errors are minor issues related to > templates and use of legacy headers (iostream.h, et al). I am able to > move forward by fixing a couple of source files. But in the long term, > this might be a roadblock for my project where I want to perform > static analysis of legacy code bases using a combination of dehydra > and treehydra, derive relevant information and generate certain > reports. > > Thanks. > > - Praveen > > On May 1, 7:18 pm, Benjamin Smedberg <[EMAIL PROTECTED]> wrote: > >> Praveen Bhaniramka wrote: >> >>> This is probably a gcc question but I will ask this anyway. >>> >>> I am trying to use Dehydra on a legacy code base. Since the base >>> compiler used to build Dehydra is gcc 4.3.0, g++ reports a bunch of >>> compiler errors and exits before it gets to invoking the Dehydra >>> callbacks. >>> >>> Is there any way to force gcc to ignore these compilation errors? >>> Since my target is to perform static analysis of this code base, I >>> don't really care about these errors. >>> >> Depends on the actual errors. Why don't you post them? It's possible that >> flags such as -fpermissive can fix things... it's also possible that you >> just need to modify your source a little bit to add new #include files, >> because GCC 4.3 doesn't automatically include system headers the way >> previous version did. See "Header dependency" >> athttp://gcc.gnu.org/gcc-4.3/porting_to.html >> >> --BDS >> > > _______________________________________________ > Dev-static-analysis mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-static-analysis > _______________________________________________ Dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
