PC-Lint for C/C++ V9.0

PC-Lint / FlexeLint

Nue in Version 9.0

Hersteller: Gimpel Software

Aktuelle Version: 9.00L / Betriebssystem: Windows bzw. Linux/Unix

Neu in Version 9.0 von PC-Lint / FlexeLint

Nach über 7 Jahren (!) ist im September 2008 eine neue Version von PC-Lint/FlexeLint erschienen.
Das Warten hat sich gelohnt! Lesen Sie was Dr. James Gimpel selbst zu Version 9.0 schreibt.
Die neue Version 9.0 bringt eine Fülle von neuen Checks und Kontrollen:
  • Multi-Thread Support
  • Verfolgung von statischen Variablen
  • Pre-Compiled Headers
  • Dimensional Analysis
  • Stack Usage
  • verbesserte MISRA Unterstützung
  • Side Effects
  • verbesserte Output Optionen
  • Pre-Determined Predicates
  • uvm.
Nachfolgend die komplette Liste aller Neuerungen:

1.1 Important New Features

Pre-compiled Headers -- Pre-compiled headers, as users of C and C++ systems are well aware, can dramatically reduce the time spent in processing multiple modules. See Section 7.1 Pre-compiled Headers.

Static Variable Tracking -- We now incorporate variables of static storage duration in our value tracking. These include not only variables that are nominally static, as local to a function and local to a module, but also external variables.
See -static_depth(n) and flag -fsv in Section 6. Static Variable Tracking.

Thread Analysis -- We examine multi-threaded programs for correct mutex locking and report on variables shared by multiple threads that are used outside of critical sections. See Section 8. Multi-thread Support

Stack Usage -- We can report (Note 974 in Section 13.5) on the overall stack requirements of any program whose function calls are non-recursive and deterministic (i.e. calls not made through function pointers). This is very useful for embedded systems development where the amount of stack required can be mission critical. A complete detailed report of stack usage for each function is available as well. See +stack() in Section 5. Static Usage Report.

-deprecate option -- The user may deprecate particular symbols in any of the following categories: function, keyword, macro, and variable. See Section 2.5.7 -deprecate.

Message Enhancement and Control -- You may now enhance any message parameterized by symbol so that the symbol's type is also given (See Section 2.5.23 +typename).
You may suppress any message parameterized by symbol on the basis of the type of the symbol (See Section 2.1.8 -etype).
You can suppress messages parameterized by string on the basis of that string (See Section 2.1.7 -estring.)
You may activate a message for a particular symbol (or set of symbols) that is otherwise inhibited (See Section 2.1.5 New Interpretation for +esym).
You may suppress a message while calling a particular function (see Section 2.1.1 -ecall),
while calling library functions (see Section 2.1.3 -elibcall) and while invoking library macros. See Section 2.1.4 -elibmacro.

Enhanced MISRA Checking -- Continued improvements have been made to our suite of MISRA checks. These include detection of recursion, support for the MISRA 2 'underlying type' concept and determination of side effects for functions. See the enabling files au-misra1.lnt for MISRA 1 and au-misra2.lnt for MISRA 2.

Source-echo mode -- You can optionally embed messages within the context of the original source code. See Section 2.4.2 -/+source(sub-option...).

html support -- Output can appear in a form suitable for a browser and handsomely color coded. See Section 2.4.3 +html(sub-option...).

Program Information -- A comprehensive collection of information about your program is optionally provided yielding information on files, types, symbols and macros for simple viewing or in a manner absorbable by a database or spreadsheet. This information can be used for many purposes including naming-style conventions. See -program_info in Section 10. Program Information

Macro Scavenging -- This feature turns PC-lint/FlexeLint into a seeker of built-in macros supported by a compiler and lying about within compiler header files. This is perfect for the unknown compiler with long and forgotten macros ready to trip up a third party processor such as PC-lint/FlexeLint. See Section 2.5.14 -scavenge.

NULL pointer check -- By setting a single flag, all pointers returned by functions will be assumed to have a possible NULL value unless specific return semantics have been given for the function. See Section 2.3.8 NULL-can-be-Returned flag (+fnr).

New semantics -- A number of new semantics have been added to the -sem option: initializer indicates the member function can be relied upon to intialize all the members. inout(i) indicates that the ith parameter will read as well as write to its (indirect) argument. pod(i) indicates that the ith argument requires a pointer to a POD (Plain Old Datatype). pure can be used to indicate that the function is a pure function. A number of new semantic flags support multi-threading analysis: thread, thread_lock, thread_unlock, and thread_protected. See Section 4. Semantics

1.2 New Messages
Version 9 has some 87 new messages. Some of the more prominent of these are as follows:

Read-Write Analysis-- Ever wonder whether each assigned value to a (local) variable actually has a chance of being used before another value is assigned to the variable or before exiting the program? We now detect this condition. See Warning 438 in Section 13.3 and Info 838 in Section 13.4.
Appropriate options allow the programmer to customize these to suit his or her programming style (See Sections 2.3.6 Initialization-is-considered-a-Write flag (-fiw) and 2.3.7 Initialization-by-Zero-is-considered-a-Write flag (-fiz).

for clause Scrutiny -- for clauses are now subject to intense scrutiny. We complain if the variable tested in the 2nd expression is not the same as the variable modified in the third or the variable initialized in the first. (Warnings 440, 441 and 443). See Section 13.3 C Warning Messages. We warn if the testing direction (2nd expression) seems inconsistent with the increment direction (3rd expression), (Warning 442), or if the expression tested is inconsistent with the expression incremented (Warning 444) or if the loop index variable is modified in the body of the loop (Warning 446). See Section 13.3 C Warning Messages.

Pre-determined Predicates -- We can detect in a variety of circumstances that the value of a predicate is pre-determined to be true or false. For example:
unsigned u;
... ( u & 0x10 ) == 0x11
is always false (Warning 587 in Section 13.3) or
unsigned u;
... ( u = 2 ) != 1
has a predictable outcome barring overflow (Warning 588 in Section 13.3), or
int n;
... ( n % 2 ) == 2
will always be false making the usual assumptions about integer division( Warning 589 in Section 13.3), or
int n;
... ( 5 << n ) < 0
which will not be true unless there is a standards violation (Warning 590 in Section 13.3).

Constants -- Constants come under careful examination. Within string or character constants, we look for the psuedo-hex character \0xFF (Warning 693 in Section 13.3), decimal characters following an octal escape sequence (Warning 692 in Section 13.3) or the embedded nul Info 840 un Section 13.4 We also look for numeric constants that have different types depending on language dialect (Warning 694 in Section 13.3).

Expressions -- We report on compile-time zero's being added, multiplied, ORed, etc. to expressions (Info 835 in Section 13.4) and deducable zero's added, multiplied, etc. (Info 845 in Section 13.4). Our order-of-evaluation errors have been extended to include the case of functions modifying objects (Info 864 in Section and the suspicious looking: p ? a : b = 1 Warning 1563 in Section 13.7. We also look for non 0/1 assignments to boolean typed objects (Warning 1564 in Section 13.7). We issue warnings about unusual sizeof arguments (Info 866 in Section 13.4).

const qualification -- We now report on global or static variables that could be made const (Info 843 in Section 13.4) and global or static pointers that could be declared as pointing to const (Info 844 in Section).

Unusual Declarations -- We report on the following declaration
int a:5;
as its meaning is not defined by the standard (Info 846 in Section 13.4). We also look for assignment operators that do not return const (Warning 1792 in Section 13.8).

Initializer Functions -- A new feature of Version 9 is the notion of an Initializer. (See Section 4. initializer semantic) Message 1565 warns when an initializer fails to carry out its mission and message 1566 points out when an initializer may be needed. See Section 13.7 C++ Warning Messages

Include Guards -- Headers are examined to determine whether they contain standard include guards. See Warning 451 in Section 13.3 and Note 967 in Section 13.5.

Pointer and Reference Anomalies -- New messages that involve the ever dangerous pointer and the innocent appearing reference are as follows. We look for
- pointers to auto being assigned to a member of the current class, Warning 1414 in Section 13.7.
- pointers to non-POD class being passed to POD-seeking functions, such as memcpy Warning 1415 in Section 13.7.
- string constants assigned to non-const char pointers, Info 1778 in Section 13.8.
- an uninitialized reference used to initialize another reference, Warning 1416 in Section 13.7.
- a reference member not appearing in a mem-initializer, Warning 1417 in Section 13.7.
- returning the address of a reference parameter, Info 1780 in Section 13.8.
- passing the address of a reference parameter into the caller's address space, Info 1781 in Section 13.8.
- assigning the address of a reference parameter to a static variable, Info 1782 in Section 13.8 and Note 1940 in Section 13.9.

Unreferenced (but constructed) class variables -- Ever try to find all those unreferenced Cstring's? We didn't complain in the past because technically speaking they were referenced by their own constructor. Such variables now get a new Info 1788 in section 13.8 so they can be picked out and eliminated.