Gimpel Software was founded in 1984 for the purpose of providing
software tools for programmers. Its focus in recent years has been the static
analysis of C and C++ programs. We offer two products in this area:
PC-lint for C/C++ (current version 9.00) is configured to operate under
Windows 10, Windows 8,
Windows 7, Vista, XP, NT, 2000, 98, ME and 95; PC-lint also runs under MS-DOS.
FlexeLint for C/C++ (current version 9.00) represents the same
functionality as PC-lint but it is distributed in obfuscated C source code. As such
it may be compiled and run on any platform that supports ANSI C.
PC-lint/FlexeLint Mission Statement
The purpose of PC-lint/FlexeLint is to find bugs, errata, inconsistencies, redundancies,
and nonportable constructions in C and C++ programs through the static analysis
of the source code. It is the nature of such products that occasional
undeserved warnings are produced. It is a secondary goal to provide as high a
wheat to chaff ratio as the art will allow, and where false hits cannot be
avoided to provide a sufficiently flexible scheme of message suppression so that a
clean lint will always be possible.
It is not the purpose of these products to enforce an arbitrary coding style nor
to provide a compilation of program metrics.
Static vs. Dynamic Analysis
By dynamic analysis, we mean executing a program. This can be done by compiling into
machine code and running the code, or by interpreting the program (either directly
or by first converting into an intermediate form). By observing the behavior
of the program, it is tempting to presume to know all about it. Dynamic
analysis is an essential part of programming, since no programmer could claim his
or her program to be complete unless it actually ran according to expectations.
A novice programmer
can be beguiled into thinking that his job is accomplished because his chosen
set of inputs leads to non-erratic behavior. Experience, however, tells us
that whereas testing can show the presence of bugs, it can never demonstrate
their absence. The number of combinations of inputs to even a relatively simple program can
be astronomically high and in general it is completely impractical to test all
combinations of input.
Static analysis on the other hand, is not confined to one set of
inputs. If, for example, somewhere in the code, a signed quantity is
compared with an unsigned quantity, the signed quantity gets promoted to
unsigned! No harm arises until the signed quantity is actually negative.
A static analysis will discover the problem without the programmer having to concoct
a set of inputs that will deliver a negative to the proper site.
Or consider a construct that the C or C++ standard considers
"implementation dependent" such as the order of evaluation of sub expressions
in a larger expression or the order of initializations in a C++ program.
By making many test runs while using the same compiler you will probably not
discover any portion of your code that would be vulnerable to such dependencies.
However, if you were to port your application to a new operating system, or obtain a
new compiler, or simply change the optimization settings of your current
compiler, the implementation dependent order assumptions can change and trigger a
bug in what seemed to be solid code.
Static analysis has a different perspective
than a compiler. Rather than finding a way that your program can be
interpreted, it looks for ways in which your program might be misinterpreted.
Another commonly occurring class of Warning is the redundant element. If
a particular function, for example, is not being called, then is the function truly
redundant or should it have been called but, through some oversight, wasn't. Clearly,
only the programmer can answer that question but it is
a question that doesn't arise during dynamic analysis.
There's an interesting analogy with the health care profession. Dynamic
testing is like emergency room care whereas static analysis is like preventative
care, such as maintaining a
healthy diet and exercise program. If your system crashes, the obvious tool to use
is the dynamic test, i.e. a traditional debugger, just as the obvious place to
take a person who has just been in an accident is the emergency room. However, just
as good health practices faithfully followed can help to keep you out of the emergency
room, so a conscientious use of static analysis can help to keep your program from
failing. No analogy is perfect and the degree to which it is not, actually
favors static analysis. If your system crashes, you might as well run the static
analysis first because if the bug is found, the offending line will be explicitly
indicated. But to convince yourself of this, you need to run a static analysis on
your own code.
Thus, static analysis can be an extraordinarily effective complement to
Home | Contact
PC-lint and FlexeLint are trademarks of Gimpel Software LLC
Copyright © 2016, Gimpel Software LLC, All rights reserved.