In his article, the author discusses the advantages of the static program analysis methodology over the compiler-provided analysis. He explains the working principles and specifics of both techniques and describes his experience of using static analysis tools by two examples, clang and Coverity, with useful comments on each.
In this paper, the authors discuss an emerging class of software bugs called optimization-unstable code, which gets discarded by compilers while performing optimizations due to undefined behavior, thus leading to a range of issues from incorrect functionality to missing security checks. They give examples of unstable code and offer a new model of this type of bugs. Based on this model, the authors have developed a static analyzer Stack designed specifically for detecting unstable code. A complete description of the implementation, searching strategies and algorithms of the analyzer is given. According to the authors, they used their tool to check a number of software systems, and found a considerable amount of unstable code issues of various types which were reported to, and then confirmed and fixed by developers. Some examples of these errors are also given in the paper.
The paper reports a research conducted by the authors in an attempt to find out the factors that prevent software developers from widely and regularly using static code analysis tools to find bugs. The research was based on the interviews of 20 software developers with considerable experience of using static analysis, their answers being grouped into several categories representing different aspects of using static analysis tools. Analysis of these responses has allowed the authors to draw certain conclusions about the problem they are concerned with. The methodology of the study and related work are described in detail as well as examples of interviewees' responses. At the end of the paper, some conclusions are drawn regarding how current static analysis tools should probably develop, the participants' ideas taken into account.
Static analysis is of little value to the organization when being used inappropriately. Cynthia Dunlop gives 10 tips on how to rationalize the way static analysis is applied to the development process in order to make it more useful and valuable. These tips basically concern the ways of managing and configuring rules and rule sets, revising the static analysis policy accepted in the company, and expanding the scope of analysis.
The article is a review of the built-in static analyzer in the new Eclipse version. It includes screenshots demonstrating how to customize the tool and how it works.
Programming languages have many classes of bugs in common, but since every language has its own specific features, the harmful effect of identical bugs may vary from catastrophic to mild depending on the language. It also means that every language is vulnerable to certain types of bugs. Therefore, static analysis is most effective when it employs different techniques to fit the specifics of each language. In his post, the author discusses the difference between static analysis of C/C++ applications and Java-applications. He describes the most typical and critical bugs of each language and explains which static analysis algorithms should be used to diagnose them.
The author explains the static program analysis methodology at the fundamental level through the halting problem. Static analysis from this viewpoint is an attempt to predict the program behavior and therefore to solve the halting problem for particular cases. The author uses an example of determining register signs in a sample program written in a simple machine language to show how static analysis fulfills this task. At the end of the article, there is a set of exercises to involve the readers into further improving the author's algorithm and thus acquire a better understanding of its principles.
Static analysis is a valuable methodology of bug fixing, but, as the article author claims, it offers important challenges to developers. These challenges relate more to psychological and social aspects of human behavior rather than technical issues. It means that programmers in a company which is going to use static analysis will tend to resist the changes caused by accepting a new practice and discipline implied by use of a static analysis tool. Flash Sheridan describes methods to avoid these issues or reduce their impact (such as allowing external specialists to carry out administration and configuration of integrating static analysis; get developers focused on quality instead of providing stable metrics and smooth running of the tool; etc.), ways to make usage of a tool more effective (prioritizing defects and ignoring obsolete code fragments), and also gives tips on some technical aspects of handling a static analyzer (symbol highlighting, defect tracking systems).
In this short post, the author tells us about his experience of using two static analysis tools each of which provides its own technique - Address Sanitizer (ASan) and Clang Static Analyzer.
The post focuses on the false idea that static analysis tools are testing tools or can be a good substitute for them. The author explains the difference between various kinds of testing and static analysis bringing out the point of the latter and its role in development. He agrees that static analyzers are necessary tools, but they are intended for detecting a "narrow band of code-related defects".