Compilers seem to be getting smarter all the time. If you fire up Borland's Delphi development environment or Visual C++ and start writing code, you'll notice a feature called "syntax-directed highlighting," which color codes program keywords, comments, and the like. In Visual Basic, when I enter a line of code in my program editor, the syntax is immediately checked for mistakes. If I forget to include a matching parenthesis, I'm immediately notified of my error. These features started me thinking about the debugging process and led me to ask the question, "Why haven't compiler vendors done more to automate the debugging process in the same manner as syntax checking?" Much like a spellchecker in a word processor, you'd think a debugger would be able to run as a background task, evaluating and instrumenting your source code during development.
Currently, the typical debugging tool in the programmer's arsenal is a run-time debugger, usually built into the development environment of your compiler. Okay. So you can set breakpoints, step through code, and see variables instantiated. This is only a step away from including printf statements in your program. Sure, there are other tools that let you check array bounds, look for memory corruption, and detect orphaned pointers. The problem is that a tool is only as good as the programmer using it. Too often, debugging is an afterthought that is pursued only after a large portion of the project has been developed.
Clearly, there are many different types of bugs, and no single tool can catch them all. The process of detecting memory errors, however, can easily be automated. One popular approach links in a library of functions, which is called as your program executes. The library reports on memory leaks and corruption. An interesting twist on this idea is used in Great Circle, an automatic memory manager from Geodesic Systems. This tool provides a library that performs the equivalent of automatic garbage collection. Instead of calling malloc or new, you call one of Great Circle's memory-management routines. The library monitors pointer variables and automatically frees them when they are no longer used.
Tools such as StratosWare's MemCheck for Windows read object code generated by the compiler and look for processor instructions that access memory. Memory-access instructions are then modified to check for corruption. Source-code instrumentation tools such as Parasoft's Insure++ place test and analysis functions around every statement in your program. At compile time, these functions collect information about data structures, pointers, and memory and store it in a database. At run time, values and memory references are checked against this database. This approach allows the tool to catch errors in static and dynamic memory, as well as stack memory.
So, how can these tools be better integrated with compiler environments? For tools that work at the source-code level, the key is in the compiler's parser. Syntax-directed highlighting and syntax checking are possible because the editor has implicit knowledge of the compiler's parser and access to information in the parse tree. Currently, third-party vendors can create a programmer's editor with similar features, but must write their own parser to accomplish the task, thus duplicating a feature already built into the compiler. The same problem exists for vendors creating debugging tools that rely on source-code instrumentation. Again, these developers must reinvent the wheel.
What if compiler developers provided a standard interface to the compiler's parser? This is the question the people at Parasoft are currently asking. Third-party developers would no longer be forced to write parsers for each language or variant they wish to support. Instead, they could use a piece of technology already built into the compiler. The compiler company would benefit from additional third-party support for their product. Ultimately, all of us will benefit from a class of new tools seamlessly integrated into the development environment.
But defining a standard interface to compiler-parser technology all starts with Microsoft, Borland, Symantec, and other compiler vendors. I urge them to contact the people at Parasoft, or me directly.
Michael Floyd
executive editor