Q&A With GrammaTech

May 21, 2008
Paul Anderson, the vice president of engineering, GrammarTech, took set some time aside from his schedule to discuss CodeSonar and CodeSurfer with us.

Paul Anderson, the vice president of engineering, GrammarTech, took set some time aside from his schedule to discuss CodeSonar and CodeSurfer with us.

ED: Can you give a little overview and history of CodeSonar and CodeSurfer?

Our main product is CodeSonar, an automated source-code analysis tool that performs a whole-program analysis and finds defects in C/C++ code. CodeSonar has been available for three years and uses program-analysis infrastructure from CodeSurfer, a tool that GrammaTech has been selling for nine years. CodeSurfer is based on research conducted at the University of Wisconsin.

ED: What kinds of problems can CodeSonar and CodeSurfer find?

CodeSonar finds flaws where the fundamental rules of the language are broken. Examples include buffer overruns, leaks, race conditions, null pointer dereferences, and uninitialized variables. It also finds inconsistencies in code that which while not necessarily bugs per se, indicate that a programmer may have misunderstood something. These correlate well with real bugs. Another class of flaws is those where an API is being misused. Finally, users can add their own checks, even sophisticated ones.

GrammaTech has focused on depth rather than breadth. CodeSonar does a superb job of finding the core problems that plague developers. For example, many different effects can contribute to the cause of a buffer overrun: integer arithmetic, pointer arithmetic, static allocation, dynamic allocation, aliasing, interprocedural effects, and others. CodeSonar understands the complex effects, which enables it to find more types of buffer overruns while maintaining a low level of false positives.

CodeSonar targets programming errors that adversely impact reliability, but some of these errors can also create security vulnerabilities. Buffer overruns are a good example. For this reason, some of our customers use our tool for security reviews.

ED: What were some of the lessons gained from developing and using CodeSonar and CodeSurfer?

Some flaws are easy to find with high precision and can be explained with easy-to-understand warning reports. However, the nastiest flaws are often very subtle and arise from interprocedural effects. While a tool that targets hard-to-find flaws it will have less precision (i.e., more false positives) and generate reports that require more thought from the user, the payoff is much greater because so many serious defects have complicated roots. It is easy to create a tool that finds simple flaws, and some users like such tools because the generated bug reports are trivial to interpret; there is actually a lot of pressure on vendors to dumb down the analysis. However, GrammaTech has resisted this temptation. Our customers develop avionics, medical, and other critical applications. They want their static-analysis tool to identify the serious flaws, even if it means they will spend a little longer reviewing warning reports.

ED: Can you comment on the current state of affairs with respect to static analysis tools?

Today, there are a large number of static-analysis tools. At one end of the spectrum are lint-like tools, which are useful but generate a lot of false positives; they are best at enforcing coding standards. At the other end are sophisticated model checkers that are very powerful but operate on an abstract specification of a program; users need to have expertise in model checking to use them. There is a sweet spot that has proven to be popular with users that balances false positives, false negatives, and performance. The companies in this spot are Coverity, GrammaTech, and Klocwork. From what we have heard, Coverity and Klocwork have biased their tools heavily toward eliminating false positives, but at the cost of missing many bugs. GrammaTech reports more complex bugs, but can have a slightly higher level of false positives. Many GrammaTech customers write mission-critical code, such medical device or avionics software, and they like how CodeSonar identifies more bugs.

ED: Has the increase of applications requiring higher levels of safety and reliability affected the importance of static analysis tools?

It is definitely a driving force. Regulatory agencies are pushing for the use of these tools by developers in response for the need for extra safety and reliability. For example, the FDA has an explicit policy to speed the adoption of these tools. Many of our customers write or review safety-critical code. NASA, the FDA, GE Aviation, Lockheed Martin, Cardinal Health, Zoll Medical, and other similar organizations use CodeSonar.

ED: How have improvements in IDEs and system performance affected the adoption of static analysis tools?

IDEs are great and improve programmer productivity. CodeSonar integrates seamlessly with IDEs, including Eclipse, so developers can analyze code without making changes to their development environment or build system. However, we have found that displaying the warning reports in an IDE is not ideal. One reason is that it is difficult to summarize a complex bug clearly within an IDE. A bigger reason is that results are reviewed by a wider audience than developers. Managers want to look at warnings, categorize results, create reports, see trends, and identify problem spots. They don’t want an IDE and they don’t want to have to install software. CodeSonar has a Web-based GUI (graphical user interface) that reduces setup and makes it easy for teams to manage results. In addition, the interface is uniform across build environments, which is handy because many of our customers are using multiple toolchains. Improvements in system performance have been instrumental in making this class of advanced static-analysis tools feasible.

About the Author

William G. Wong | Senior Content Director - Electronic Design and Microwaves & RF

I am Editor of Electronic Design focusing on embedded, software, and systems. As Senior Content Director, I also manage Microwaves & RF and I work with a great team of editors to provide engineers, programmers, developers and technical managers with interesting and useful articles and videos on a regular basis. Check out our free newsletters to see the latest content.

You can send press releases for new products for possible coverage on the website. I am also interested in receiving contributed articles for publishing on our website. Use our template and send to me along with a signed release form. 

Check out my blog, AltEmbedded on Electronic Design, as well as his latest articles on this site that are listed below. 

You can visit my social media via these links:

I earned a Bachelor of Electrical Engineering at the Georgia Institute of Technology and a Masters in Computer Science from Rutgers University. I still do a bit of programming using everything from C and C++ to Rust and Ada/SPARK. I do a bit of PHP programming for Drupal websites. I have posted a few Drupal modules.  

I still get a hand on software and electronic hardware. Some of this can be found on our Kit Close-Up video series. You can also see me on many of our TechXchange Talk videos. I am interested in a range of projects from robotics to artificial intelligence. 

About the Author

Paul Anderson | Vice President of Engineering

Dr. Anderson received his B.Sc. from Kings College, University of London and his Ph.D. from City University London. Dr. Anderson’s work has been reported in numerous articles, journal publications, book chapters, and international conferences.

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!