| Platforms:
- PC-lint for C/C++:
- Microsoft Windows
- DOS (built-in DOS extender)
- OS/2 (32 bit)
Compatibility:
- supports K&R C, ANSI C, ANSI/ISO C++
- explicit support for Microsoft, GNU 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
Message Suppression:
- by number
- by number and symbol (including wild cards)
- one-line suppression
- by macro
- for library headers, by number (a header is library depending on
how it is included; this can be overridden via user options)
- for specified functions, by number
- for expressions
Flexibility:
- indirect files (nested to any depth) can contain filenames,
options, environment variables
- format of error messages can be customized to support a wide
variety of editors/IDE’s
- all options can be embedded in user code
Special Checking Facilities:
- value tracking to detect subtle initialization and value misuse
problems
- Inter-function Value Tracking -- The powerful inter-statement
value tracking has been extended to cross function boundaries.
Functions called with specific values are later processed, with these
values used to initialize parameters. To take full advantage of
inter-function tracking, a multi-pass operation has been introduced.
The user can control the number of passes.
- with value tracking as an enabling technology, we support
‘semantics’ checking for almost 100 library functions, this checking
can be extended to user functions
- 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
- checks flow of control for possibly uninitialized variables.
- explicit support for a subset of the MISRA (Motor Industry
Software Reliability Association) standard
- other special torture tests
Performance:
- fast one-pass operation, with a multi-pass option for
inter-function value tracking
- robust - tables will expand as needed to handle large applications
30 day money-back guarantee
What is Static Analysis?
Won't my compiler do syntax checking?
Does C++ make lint obsolete?
How do I separate the wheat from the chaff?
What's the difference between PC-lint and
FlexeLint?
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.
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.
| For more information please contact the
MicroWay sales team: |
Head Office
MicroWay Pty Ltd
PO Box 84,
Braeside, Victoria, 3195, Australia
Ph: 1300 553 313
Fax: 1300 132 709
email: sales@microway.com.au
ABN: 56 129 024 825 |
Sydney Sales Office
MicroWay Pty Ltd
PO Box 1733,
Crows Nest, NSW 1585, Australia
Tel: 1300 553 313
Fax: 1300 132 709
email: sales@microway.com.au
ABN: 56 129 024 825 |
New Zealand Sales Office
MicroWay Pty Ltd (NZ)
PO Box 912026
Victoria Street West Auckland 1142, New Zealand
Tel: 0800 450 168
email: sales@microway.co.nz |
 |
|