How PC-Lint assists C/C++ developers ?
PC-lint is a command-line tool for performing static code analysis, indicating suspicious or plain wrong issues in source code.
PC-lint can be integrated into IDEs as an external tool, and the format of the warning messages can be adapted to the form the IDE is able to recognize and process.
PC-lint can be used for quality assurance of C source code and checking the code for conformance to coding guidelines such as MISRA C or MISRA C++. It also includes checks for problems unique to parallel programs built on POSIX threads.
What is Static Analysis?
PC-lint and FlexeLint will look across your entire program that may consist of many C and/or C++ modules and find bugs, glitches, inconsistencies, and redundancies. It can find problems that may not be caught in initial testing. Some bugs lie dormant for months and years and their ultimate eradication can be time consuming and expensive. It pays to expose errata while the code is still fresh in the mind of the programmer and while the original programmer is still employed by the company responsible for the software.
Won’t my compiler do syntax checking?
Compilers do an excellent job of finding syntax errors and most will produce warnings. But PC-lint and FlexeLint begin where compilers leave off. PC-lint/FlexeLint contains numerous features such as precision tracking, initialization checking, value tracking, strong type checking and macro analysis that compilers do not have. Also PC-lint/FlexeLint looks across a set of modules to find intermodule inconsistencies and redundancies. This compilers do not do.
Does C++ make lint obsolete?
ANSI C and C++ have solved the problem for which Unix lint was originally developed, i.e., to ensure consistency of function calls across module boundaries. But most other sources of errors in C code remain in C++. These include uninitialized variables, order of evaluation dependencies, loss of precision, potential uses of the null pointer, etc. (See Representative Checks on the next page).
In addition to problems inherited from C, C++ has added new opportunities and requirements for static checking. For example, it is now possible to report that a constructor has not initialized a member. This deficiency could not be reported for C code because responsibility for initialization is not uniquely assigned to a given function (i.e. there are no constructors in C).
There have been numerous articles and books on the C++ language written by such prominent authors as Cargill, Koenig, Murray and Myers describing numerous do’s and don’ts. Although it is a formidable task for even the expert to hand check each line of source code for conformity to accepted principles of good design, such checks can be automated and most have been incorporated in PC-lint/FlexeLint.
How do I separate the wheat from the chaff?
We have taken several steps so that our users are not inundated by a mass of insignificant messages in which they may have no particular interest.
All messages are carefully crafted to make use of all available information so that they have an inherently high wheat-to-chaff ratio. We have four levels of message (Error, Warning, Informational and Elective Note) and distinguish between two kinds of header (library headers vs. project headers).
Messages can be suppressed by number, by symbol, by macro, by line and by header type. Through a selection of options, you in effect tailor your own subset of the C/C++ language.
- supports K&R C, ANSI C, ANSI/ISO C++
- explicit support for Microsoft, GCC and most other major compilers and libraries
- support for most major embedded-system compilers including bit addressing.
- numerous options to support rogue compilers
- scalars sizes can be specified for cross-compiling
Special Checking Facilities:
- value tracking of auto and static (even global) variable, to detect subtle initialization and value misuse problems
- Inter-function Value Tracking — The powerful inter-statement value tracking crosses function boundaries. Functions called with specific values are later processed, with these values used to initialize parameters.
- Multi-Pass — To take full advantage of inter-function tracking and static variable tracking, a multi-pass operation has been introduced. The user can control the number of passes. (See Designer’s Notes)
- with value tracking as an enabling technology, we support ‘semantics’ checking for almost 100 library functions, this checking can be extended to user functions (see function mimicry)
- optional strong type checking (typedef-based) with a rich option set to detect nominal type differences. You can even form a fully checked type hierarchy of scalar types using only typedef
- user-defined semantic checking for function arguments and return values
- find unused macros, typedef‘s, classes, members, declarations, etc. across the entire project (see weak definials)
- checks flow of control for possibly uninitialized variables.
- explicit support for a subset of the MISRA C and MISRA C++ (TM) (Motor Industry Software Reliability Association) standards
- other special torture tests
PC-Lint licenses are per user or for a defined number of users in a team.