Main menu:

Site search

Categories

Archive

Static analysis newslets

I’ve been in interpreter-land lately, but I do help out a bit with static analysis projects when I get the chance. So I’d better post an update here on some interesting developments that haven’t been publicized yet.

First, Keith Schwartz (one of our interns) is making great progress on automatic const-correctification for Mozilla. The basic idea is to put const on as many declarations as possible without breaking the code or introducing casts. Keith has devised an algorithm based on type inference. Currently, he’s working on the Treehydra code to extract the type constraints from code. Because C++ is so complicated, there are a ton of details, and he’s had to master the insanity of GCC intermediate representations of pointers to member functions and calls through them. (If by chance, any readers know of a non-insane way to access them in GCC, let us know.)

Second, the Cairo folks were kind enough to give me an hour to talk about static analysis with the Hydras at their recent meetup. They already had 2 static analysis applications in mind. One was ensuring that internal-only return codes aren’t returned from the public API. The other was checking that integer and fixed-point values, both represented by C ints, aren’t mixed together. I think both of these can be formulated as type checking or inference problems.

I’m hoping we can extract a generic Treehydra type inference library from Keith’s code for the Cairo problems and others. One issue here is that Cairo is C, while Keith’s been using the C++ ASTs for his work. I don’t even know if Treehydra can read C ASTs at this point, but I think Treehydra’s design makes extending to C not too hard.

Comments

Comment from tglek
Time: September 5, 2008, 11:35 am

Congrads, I didn’t realize that by talking with cairo guys you meant doing a presentation!

We use the IR GIMPLE, so the code should already work on C except where we poke at C++ types. C type representation sucks.
I suspect getting treehydra to do C will be a matter of making sure that it doesn’t call C++ FE functions and weaking linking them, which should take almost no time at all to do.

Another C type analysis analysis is to redo my prcheck tool in treehydra such that it can be integrated into the build. Same idea, ints and ints typedefed to PRBool are to be treated differently.