What About JavaScript In Dehydra?
April 4th, 2007
Most static analysis tools don’t let you script them. Oink is an example of that. Adding a new analysis requires extending an existing tool with a feature which may not fit in smoothly or writing a new tool in C++ with the corresponding boilerplate to handle command-line arguments, etc.
At the other extreme lives UNO which has a DSL that is designed strictly for solving control-flow programs.
I chose JavaScript for Dehydra to get the power of a full-blown (and memory safe) programming language while keeping JS’s view of the code under analysis as simple as possible. I think I got the C++/JS mix just right, the C++ codebase is growing slowly, yet I add JS scripts for any little task.
Additionally JS came in handy for publishing the data on the web. I wrote a script to determine the class inheritance graph. Then I added a little prefix to the file produced, combined it with jsviz and ended up with a really slow and unusable, but somewhat pretty class browser. This could evolve to be a rather neat way to supplement LXR.
April 5th, 2007 at 3:47 am
Very interesting. It’s nice to see your progress reports on this. I’ve had a similar idea for quite some time, basically a LXR that understands the code it’s indexing. Parsing instead of just trying to grep function names or identifiers heuristically. I have a half-assed, not-at-all-finished beginning of a mockup (hehe) for Python, using its built-in parser. Just to see how tricky it is, and how to extract interesting meta-data.
Other thoughts are basically a search interface with CSS-like selectors. If you want to see all integer variables in all functions that has “tree” in the function name, you can get that. You could also add things like “trace identifier” (e.g. a variable) and backtrace through what calls can end up touching it.
Of course, for duck-typed languages, things change a bit. But the general idea would extend to pretty much all high-level languages. Lucene could work as the data backend, since it’s fast and cross-platform. Analysis in Java is probably not a good idea, though. I’ve pondered using Lisp for as much as possible, or native tools for each language (Elsa for C++, since C++ is a horrendous language to parse) and a common intermediate format which is then massaged and fed to a Lucene index.
Anyway, sorry for the rant. And good luck on further progress.
May 7th, 2007 at 4:57 pm
Oh, we definitely want an “ElsaXR” that actually parses. Platform-specific #ifdefs pose a problem, of course, but it’s solvable. Taras probably knows the status of this gleam in our eye better and can say more.
/be