From: CodeStandards

Table of Contents

  1. C++ Static Analysis Tools
    1. C++ Customizable Coding Standards Checkers
      1. Programming Research PRQA C++
        1. Documentation
        2. Review of Demo
        3. PRQA C++ Pricing
      2. Abraxis Software CodeCheck
        1. Codecheck Features
        2. Codecheck Initial Review
        3. Codecheck pricing
      3. Parasoft C++test
        1. C++test Features
        2. C++test Licensing
      4. Comments on Parasoft from Paul Jansen <Paul.Jansen@…> TIOBE …
    2. C++ Language Usage Checkers
      1. GCC as Everyman's C++ lint Checker
      2. FlexeLint: C++ lint on steroids
        1. Features
        2. Pricing
      3. FlawFind: Security-vulnerability Checker
    3. OINK: Framework to Build your own Static Analysis Suite
    4. 1997 Survey of C++ Static Analyzers
  2. Long term utility of static analyzers
  3. C++ Dynamic Analysis Tools
    1. Valgrind
    2. gcov/ggcov
  4. Comments From LSST Participants

C++ Static Analysis Tools

C++ Customizable Coding Standards Checkers

A subset of the full LSST package was provided to 2 vendors of C++ Coding Standard Checkers. Since we knew that some CSCheckers include runtime code coverage analysis, we provided a standalone package containing packages: base, utils, daf_base, pex_logging, execptions, and pex_rolicy and a simple build shell script (not based on eups or scons).

An LSST software tree subset, to be used for benchmarking of various code checker software, is available as a gzipped tar bundle at Benchmark software along with its companion README.

Programming Research PRQA C++

Programming Research used a subset of the LSST software suite to prepare a set of reports exemplifying their toolset. During a meeting with the vendor and DM members, the toolset was reviewed and the generated reports were discussed.

Documentation

Programming Research provided

They did not include: 'exceptions' since it requires a build to generate the header files from .m4 files. PR QA-C++ does not provide runtime coverage analysis.

Review of Demo

A brief review provided by Jon Myers:

A few of you attended today's meeting with representatives from PRQA, who provided a demo of their C++ static analysis tools.

I have been in contact with Parasoft, who also provide a similar set of tools and services; they provide a small demo of their C++ analysis product through a Flash presentation: Parasoft C++test - Demonstration

Having seen both, I though I might present my thoughts.

I was fairly impressed by PRQA's presentation, and their general attentiveness has been much higher than Parasoft's; Parasoft has generally been less responsive, have yet to provide us with ademonstration report on our code and haven't been tremendously responsive to my e-mails.

Beyond that, their tools seem very similar; here are the main differences I've noticed:

In PRQA's Favor:

  • PRQA provides regular-expression-based support for naming conventions, as far as I know Parasoft does not.
  • PRQA tests for cyclomatic complexity of code and generates control-flow graphs for functions.

In Parasoft's favor:

  • Parasoft supports automated unit test generation (!) but PRQA does not.
  • Parasoft includes support for adding and running unit tests.
  • Parasoft includes memory monitoring which shows visually the usage/leaking of memory over the course of unit tests.

Additionally, the two support slightly different sets of standards out-of-the-box; I can't say off-hand which would be better for us, but I'd expect them to be roughly equivalent. Further, both provide tutorial examples of why given rules and standards exist, including example code which demonstrates possible problems.

Overall, I'm slightly more impressed by the thoroughness of PRQA's interface for static analysis, but automated unit testing is quite a significant feature.

As became apparent during our conversation, the major concern is deciding as a group how these products should be used and deciding whether they will work well with our current workflow. Linux and Windows are well-supported by both tools, but OS X is not supported by either. Both companies seem strongly invested in GUI-based methods of running their tools, which I suspect many of our developers won't find pleasing.

PRQA provides a separate license for a 'qac++' command-line tool which takes the same parameters as g++ and outputs analysis information. This could potentially be integrated into SCons or Makefiles. This may be a better fit for our developers. License management is provided by FlexLM. (Consensus seems to be that using FlexLM over WAN is painful at best.)

Parasoft supports C++Test as an Eclipse plug-in, and also provides a command-line "batch mode" which generates reports, but it requires the highest-level license. As far as I can tell license management is provided by a Parasoft proprietary tool called pslic.

Other options:

Has any worked with Dehydra or Treehydra, the static analysis tools used by Mozilla? They seem rather green, which is unfortunate. It would be nice, if licensing or platform dependence become a large hassle, if we could fall back on some open-source analysis tools on our local machines and run proprietary tools at a central location like the SVN server.

Pass/Fail based on 'Quality Metric' during Build

Statement of need:
For structural and syntactic analysis of a source module, we will embed the PRQ-C++ command line interface into our build process. We envision a layering of checks

  • a module based static analysis check for each developer (i.e. multiple files comprise a module);
  • a multi-module based check for the QA team.

If, during the 'build' we can acquire the full pathname to each file in the module and its quality ranking, we can determine

  • if a 'Fix-It' notification needs to be sent to the responsible developer;
  • if an in-progress build needs to be aborted.

The scenario provided by Programming Research follows:

  • Analyze code from command line
  • Using a message filter that only enables messages that if violated would mean that the module is unacceptable. This would mean configuring a .p_s file to include messages that LSST decide are the ones that would make a module pass or fail if any of them, or a certain number of them were violated.
    • Generate Warning Summary Report which provides a text based table of figures that if any are non-zero (or exceed a particular threshold) would mean that the modules were unacceptable
    • Generate Warning Listing Report (text or html - GUI does html by default) to show individual cases of messages that if violated (or if exceed a limit of violations) are unacceptable. I.e. scan text/html looking for message numbers that should not be present and if they are, then look at corresponding files that have that message violation present.
  • accept or reject the file based on a criteria as decided on by LSST (ie no violations at all, or only a certain number allowed) This could then be emailed to a user to say that the module is not acceptable for the reason that it contains violations of the pre-determined message filter in 2 above, and they could then use the Message Browser to view where those violations occurred and how to go about re-coding to avoid them.

These two reports can be generated from the command line using prjdsp and errsum executable programs as supplied in the bin directory of QAC/QAC++ and they are described in The User Manual Chapter 9 - Running QAC/QAC++ from the command line. Specifically page 86 for errsum and page 88 for prjdsp.

PRQA C++ Pricing

Patrick Saletnik from Programming Research provided the following pricing details 

Here is an overview of our pricing, we use Flex LM as a license manager.
We sell both Fixed (node/CPU locked) licenses and Floating Network
Licenses which are LAN based.

I wanted to understand how you would like to use the QAC++ product?
Meaning, if you could use the licenses a certain way...where would the
users be located and how would you want them to connect?

With our floating licenses we use the 5 users to 1 FL license ratio.
Also, if you purchase a Qty 5 Floating license of QAC++, the CLI
(Command License) will be part of the Qty 5 purchase. Annual maintenance
is 20% of the license cost.

1 floating network license - $14,000 plus 20% maintenance (GUI only)
2 floating network licenses - $26,599 plus 20% maintenance (GUI only)
3 floating network licenses - $34,999 plus 20% maintenance (GUI only)
4 floating network licenses - $41,999 plus 20% maintenance (GUI only)
5 floating network licenses - $52,498 plus maintenance of 20% (This qty
5 would include the CLI or Command Line)

If you were to purchase a Floating Command Line License, the pricing
would be as follows...

1 Floating Command Line License - $36,049 plus 20% maintenance
2 Floating Command Line License - $40,599 plus 20% maintenance
3 Floating Command Line License - $44,098 plus 20% maintenance
4 Floating Command Line License - $46,548 plus 20% maintenance

If you wanted to use a Fixed License (Node/CPU Locked), you would not
have access to CLI (Command License)...

1 Fixed License - $7,000 plus 20% maintenance
2 Fixed License - $13,300 plus 20% maintenance
3 Fixed License - $18,199 plus 20% maintenance
4 Fixed License - $21,699 plus 20% maintenance
5 Fixed License - $24,499 plus 20% maintenance

Lastly, if you wanted to use our HICPP compliance module, you would add
a 20% cost to the license cost for it. An example would be...2 Floating
License w/CLI = $40,599, plus 20% = $8,119.80 and the annual maintenance
of 20% is ($48,718.80 x 20% = $9,743.76) $9,743.76 for a grand total of
$58,462.56.

Abraxis Software CodeCheck

Abraxas Software CodeCheck

Codecheck has the best price of the tools providing user customized coding standards compliance checking. However, the interface to the user customization feature appears much more convoluted than for PRQA C++. Installation is also very hands on. There is a demo version has been tried.

Look at: Sample Abraxas output for a random code on the web. Illustrates the quality metrics avialable from CodeCheck.

Look at a locally generated Abraxas Sample Output.

Codecheck Features

CodeCheck 14.0 is a programmable tool for checking all C and C++ source code on a file or project basis. CodeCheck is input compatible with all variants of Standard K&R C, Standard ANSI-C/C++, and all C and C++ compiler vendors. We support GCC-GNU Open Source C/C++ compilers. CodeCheck is designed to solve all of your Portability, Maintainability, Complexity, Reusability, Quality Assurance, Style Analysis, Library/Class Management, Code Review, Software Metric, Standards Adherence, and C++ Corporate Compliance Problems. CodeCheck? Caveats & OS dependencies.

  • "Understanding Code Check in the Corporation". How to start automating your coding standards's with CodeCheck?.
  • Supports Microsoft Visual Studio - Borland - SUN/AIX/SGI/HP and GCC/Cygwin/Eclipse Environments
  • No Limit on Rules - If you can think it up, then we can detect it! If C/C++ can be written, we can detect the issue.
  • We Support All dialects of C &C++ from 1978 to 2008 for all vendors
  • We Support All Operating Systems. Our tools run on all operating systems. Run CodeCheck? on your favorite development environment.
  • Validate code targeted to Embedded Systems - Supports ESP C++ Specification, Misra, TUVA, IAR, Ellemtel
  • Java like Exception Checking is supported for full Java like C++ Development
  • GUI Report Generator for CodeCheck - GOCHECK
  • Linux Standard Base with CodeCheck Validate C/C++ to LSB Standard.
  • All Embedded [ ESP ] C and C++ Compilers - Green Hills, Keil, PIC, IAR, VxWorks?
  • Code-Check any source from any machine ASCII or EBCDIC
  • The Elements of C++ Style: Misfeldt, Bumgardner, Gray is now included as an automated 'rule-file' 2004
  • C++ Coding Standards: Alexandrescu & Sutter 2008
  • POSIX.1 Verification System - Detect ANSI-ISO Conflicts with POSIX For Both C & C++.
  • VSS C/C++ Voting Systems Standards - FEC Software Test Standards 4.2.x & 5.4.2 - Coding Conventions Analyzer
  • FREE Misra C Checker - UK Automotive Coding Standard's 2004 [ We provide Misra-1998 & Misra-2004 ]
  • Scott Meyer's Effective C++ 2008 - Third Edition "55 Specific Ways to Improve Programs"
Codecheck Initial Review

Abraxas setup

  • Need to create a definition file which will be used by the Abraxas checker in order to exactly emulate the user's compiler. This file includes
    • the system definitions for hardware and software used during a compile and
    • the paths to the compiler's system include files (those defined using '<>').
      This file will be unique for each (OS version : compiler version) used. For LSST, the file requires the definitions used by the specific gcc compiler on the specific OS varient used on our local workstation.

      Ramifications:
      • Each user needs to build this file for his specific workstation.
      • Any change of the location of **system** include files requires the Abraxas file to be recreated.
      • Due to our creative implementation of include location, we will need to setup an environment variable defining all the include directories required for a module's build.
  • Need to have an Abraxas rules file which define the standards checks to enforce. Abraxus has many existing rule bundles from which to choose. The user may mix and match from existing bundles in order to create a specialized check, and/or the user may provide the company's Software Standards document to Abraxas for assistence in creating a rules file specialized to the company's Software Standards.

Abraxus Use 

<CodeChecker> <compiler definitions> -R<ruleset> <C++ source file>
  where:
     <CodeChecker> - executable provided by Abraxas to perform the compliance check.
     <compiler definitions> - location of (ascii formatted) compiler emulation data
     <ruleset> - location of object file defining the compilance ruleset
  Example:
     ./ccdemo g411c.ccp -Rmisra04.cco myfile.cc

Customer Support

The Abraxas customer support is extremely quick in emailing a response to an email. However the advice tendered is pedantic (e.g. you must read everything on their website in order to have any hope of correctly using this complex code written by dozens of PhDs over the last 30 years) and sometimes orthogonal to the issue. I suspect that once we started using the product, the support person would be adequate to our needs.

Codecheck pricing

To be used in a network server environment, number of "seats" reflects the number of simultaneous users of CodeCheck on your network (LAN). Network server allocation is usually controlled by a server on your LAN controlling the number of "Seats" active at any given time. Site administrators (local gurus) are to be assigned telephone support privileges with Abraxas Software.

A CODECHECK LINUX BINARY LICENSE FOR SINGLE ASSIGNEE IS $495.

A site ( geographical area ) license may be purchased as shown below for quantity user discounts. These are "floating" licenses, e.g. Just Like a Book. 

Suggested Retail: $495.00   [ Single Seat  Binary License ]

Seats	    Discount     Price/Unit Lan Fee         Support Contact

5           25%          $371       $1,856          1
10          30%          $347       $3,479          1
25          35%          $321       $8,043          2
50          40%          $297       $14,850         2

 100 + contact Abraxas Software

Parasoft C++test

Parasoft also received LSST software to be used when preparing sample reports by their toolset for our evaluation.

Parasoft has not been responsive to questions or speedy with their tool's demo. The lack of responsiveness should be considered when contemplating the tool's acquisition.

C++test Features
  • Static analysis of code for compliance with user-selected coding standards
  • Graphical RuleWizard? editor for creating custom coding rules
  • Static code path simulation for identifying potential runtime errors
  • Automated code review with a graphical interface and progress tracking
  • Automated generation and execution of unit and component-level tests
  • Flexible stub framework
  • Full support for regression testing
  • Code coverage analysis with code highlighting
  • Full team deployment infrastructure for desktop and command line usage

Platforms

  • Linux kernel 2.4 or 2.6 or higher with glibc 2.2 or higher and an x86-compatible processor
  • Linux kernel 2.6 or higher with glibc 2.3 or higher and an x86_64-compatible processor (32-bit compatibility package is required)

Compilers

  • Linux (x86 processor): GCC 2.95.x, 3.2.x, 3.3.x, 3.4.x, 4.0.x, 4.1.x
  • Linux (x86_64 processor): GCC 3.4.x, 4.0.x, 4.1.x
C++test Licensing

C++test is available in the following editions:

  • Professional Edition: A completely integrated tool suite that enables developers/testers to perform automated code analysis (with built-in coding standards/rules and any custom rules developed in the Architect Edition) and automated unit testing (with automatically-generated and user-defined test cases) from the desktop. Tests that scan multiple classes/files/directories can be performed directly from the development environment, with results immediately reported in the GUI for review/repair. Additionally, problems identified by Server Edition tests can be imported into the GUI for review/repair. The Professional edition is intended to be installed and licensed on every developer and tester desktop.
  • Architect Edition: Includes the Professional Edition functionality, and adds the RuleWizard? module, which enables the creation of custom coding standards/rules using a graphical interface. The Architect Edition is intended for use by an architect or the individual responsible for establishing coding standards for the organization.
  • Server Edition: Includes the Professional Edition functionality, and adds support for performing automated code analysis and unit testing as batch or “server” processes. The provided command-line interface can test the complete project code base and be integrated into the automated build process. Results are written to customizable reports, which can be easily accessed by team members. Additionally, developers and QA can import Server Edition test results into the desktop GUI for review/repair.

The Server Edition also provides:

  • The Team Configuration Manager (TCM) module, which enables centralized administration and sharing of coding standards/rule sets, unit testing configurations, and test assets. TCM is designed for development teams that want to ensure consistency in test practices across the team. When TCM is implemented team-wide, the architect/lead developer can configure and upload standard team-wide test settings/configurations/files, then TCM will automatically share them across all team C++test installations. TCM may be installed and run on any supported computer system (e.g., one of the developers' workstations, the server hosting a Parasoft Server Edition product, or an independent system).
  • The Code Review module, which automates preparation, notification, and tracking of peer code reviews, addresses the known shortcomings of this very powerful development practice. C++test automatically identifies updated code by scanning the source control system, matches the code with designated reviewers, and tracks the progress of each review item until closure. With the Code Review module, teams can establish a bulletproof review process—where all new code gets reviewed and all identified issues are resolved.
  • BugDetective, which simulates application execution paths—which may cross multiple functions and files—and determines whether these paths could trigger runtime bugs. Defects detected include using uninitialized memory, null pointer dereferencing, division by zero, and memory and resource leaks. Such defects may also point to missing requirements for the specific use cases corresponding to highlighted execution paths.

Comments on Parasoft from Paul Jansen <Paul.Jansen@…> TIOBE Software

I saw your comparison of static analysis tools on the web (as referred to by http://talkaboutquality.wordpress.com). This is a nice overview. Our business (www.tiobe.com) is to help companies to introduce static quality analysis tools into their organization and make sure they can monitor software quality real-time. Since we are independent we are free to say anything about a code checking tool. This mail is to share our thoughts with you about the static analysis tools you were discussing. Take it as a free advice from a static analysis tool fan.

One of the pitfalls of QA-C/C++ is that salesmen claim that QA-C/C++ rules can be modified. This is only marginally true. It is hard and it is not flexible. In the end you have to pay their consultants to make it work for you. Most companies prefer C++test for this, because it has a built-in graphical tool called RuleWizard? to create own rules. Really neat. C++test is also less expensive if you only take the static analysis part. A drawback of C++test is its poor quality of the built-in rules. It is not the number or choice of the built-in rules, but the way it is implemented. The implementation of the built-in QA-C/C++ is much better and industry-proven.

Apart from this it appears to be hard to instrument tools like QA-C/C++ and C++test. This is not done by the tool itself. So you have to write some scripting to extract compiler flags and feed them to QA-C++ or preprocess the code yourself first. Depending on your build process, this could take some effort. For this we have created a generic interface for tools such as QA-C/C++, C++test and PC-Lint. These interfaces are capable of instrumenting the static analysis tools automatically.

But maybe there is something else that might interest you. There is a new generation of static analysis tools for C++ that are capable of doing some dynamic checking statically. Examples are Coverity, Klocwork and CodeSonar?. These tools are a bit more expensive but they have more added value in the long run I think. C++test has also such an extension, called BugDetective?, but it is not as mature yet as the other 3 tools.

Just for your information. Most of our C++ customers are using C++test (80%) followed by QA-C++ and PC-Lint (both about 7%). Our multinational customers are also looking at the new generation of static analysis tools, but they are not using them yet. We are also doing some research in this area to see what is the best tool in this context. On the short term we stick to C++test as default for our customers. For this we use our large C++test rule set of about 700 rules that have been used for more than 100 MLOC of production code of mission critical systems. If you are interested in this, let me know, then I could send them to you.

C++ Language Usage Checkers

GCC as Everyman's C++ lint Checker

Many of the language checks done by the static analyzers can be done by gcc during compilation. The following extract from: GNU C++ mail archive provides the gcc command line options to perform first level static analysis on C++ code. 

PS:  here are the warnings I personally use in my g++ wrapper script w++
(notable absences -- I do not enable -Wunreachable-code nor -pedantic in my
wrapper script):

>cat ~/bin/w++ 

/usr/bin/g++ 
-ansi 
-Wno-long-long 
-Wall 
-Wextra 
-Weffc++ 
-Wredundant-decls 
-Wstrict-null-sentinel 
-W#warnings 
-Wfloat-equal 
-Wmissing-format-attribute 
-Wmissing-noreturn 
-Wpacked 
-Wshadow 
-Wunused-macros 
-Wcast-align 
-Wcast-qual 
-Wconversion 
-Wctor-dtor-privacy 
-Wdeprecated 
-Wdeprecated-declarations 
-Wendif-labels 
-Wformat-extra-args 
-Winline 
-Winvalid-offsetof 
-Wmissing-field-initializers 
-Wnon-lvalue-assign 
-Wnon-virtual-dtor 
-Woverloaded-virtual 
-Wpmf-conversions 
-Wpointer-arith 
-Wshorten-64-to-32 
-Wsign-compare 
-Wsign-promo 
-Wundef 
-Wwrite-strings 
-Wold-style-cast 
-Wno-unreachable-code 
-fdollars-in-identifiers 
"$@"

You may wonder "Why -fdollars-in-identifiers?" (Note: -pedantic warns about
even with the flag.)  I use these kinds of macros:

#define DEBUG$($1, $2, $3) $1 << "Debug: " << $2 << $3 << std::endl
#define $FOO 77 // Avoid!  prefer: int const kFoo = 77;
#define $Foo_Bar_h // Header guard.

I try to avoid macros (macro constants and macro functions) like the plague.
They do not honor namespaces.  Their heavy black jackboots walk all over
your code.  They can ruin your day.  Having a $ in their names helps keep
the hot side hot, and the code side code.

I do use them without reservation for header guards and to include/exclude
platform specific code segments, for assertions, debug droppings, and a few
other more questionable practices.  The use of the $ character is a DEC
VMS-ism I've never quite shaken out of my system.

FlexeLint: C++ lint on steroids

FlexeLint

FlexeLint will check your C/C++ source code and find bugs, glitches, inconsistencies, non-portable constructs, redundant code, and much more. It looks across multiple modules, and so, enjoys a perspective your compiler does not have.

By default, FlexeLint is a console application and is run from the command line. It can easily be set up to run from within your make file as part of a build.

FlexeLint does not provide user customizable coding standards compliance checking.

Features

PC-lint/FlexeLint will detect - For C++ ...

  • order of initialization dependencies
  • class members not initialized by constructor
  • pointer members not deleted by destructors
  • base class destructors that are not virtual
  • names hiding other names
  • improperly formed or missing assignment operators and copy constructors
  • missing destructors from classes using dynamic allocation
  • out-of-order constructor initializers
  • creation of temporaries
  • undefined and unreferenced class members initialization of a non-const reference with a non-lvalue
  • assignment operator not first checking for assignment to this
  • inconsistent use of extern "C"
  • operator delete not checking argument for NULL
  • static variables in in-line functions in headers
  • exposing privileged data
  • failure to copy a base class, or to use the base class copy constructor
  • failure to assign members and base classes
  • issuing throw within a destructor
  • assignment of an array to a base class pointer
  • inconsistent or incomplete exception specifications
  • failure to reference a virtual member function
  • a virtual function with a default parameter
  • redundant access specifiers
  • binary operators that should be non-member functions or that return references, or that shouldn't be user defined or operators that should be defined
  • function parameters that could be declared const reference
  • ill-defined increment and decrement operators
  • catch parameters that are not references
  • An examination is made of all the base class hierarchies in the entire project to determine non-virtual classes included twice, or virtual classes not included twice in any class hierarchy.
  • from value tracking information we can detect under many circumstances:
    • use of NULL pointer in unary * or ->
    • creation and access of out-of-bounds pointers
    • subscript out-of-bounds
    • division by zero
    • passing NULL pointers to selected library functions
    • data over-run conditions on selected library functions
    • Booleans that always evaluate true or evaluate false
    • inappropriate deallocation
    • memory leaks
    • unusual values passed to functions based on user-defined semantic specifications
  • from a special macro scan we can find
    • passing an expression to an unparenthesized macro parameter
    • passing an expression with side effects to a repeated macro parameter
    • unparenthesized expression-like macros
  • intermodule type inconsistencies
  • uninitialized variables (auto, static and global scalars, arrays and structs)
  • unused variables and functions
  • assigned but not accessed variables (including globals)
  • unreachable code
  • unusual expressions such as: flags & 4 == 0 (precedence error)
  • constant Booleans as in: if( x = 0 ) ...
  • indentation checking
  • suspicious use of semi-colons as in if( a > b ); not followed by else
  • strict and loose enumeration checking
  • printf-scanf format checking
  • order of evaluation errors as in: a[i] = i++;
  • unsigned comparisons with 0
  • wide variety of loss of precision errors such as int to char featuring our exclusive precision tracking
  • excessive shift values
  • loss of sign
  • suspicious cast
  • mixed signed and unsigned quantities
  • comments within comments
  • unused compile time objects, including macros, typedef’s, declarations, class’es, union’s, enum’s
  • ANSI quiet changes
  • unused headers
  • returning pointers to auto addresses and assigning auto address to static
  • externals that can be made static and hence hidden
  • declarations that can be offloaded from headers
  • name clashes within the first count characters
  • strong type checking based on typedef types.
  • possibly uninitialized variables based on flow of control.
  • overflow while processing arithmetic constants (E.g. for 16 bit integers, 200*200 overflows)
  • constant expressions that reduce to zero
  • suspicious truncations
  • suspicious loss of fraction
  • initialization irregularities (too few, too many, incorrect shape, string concatenations in)

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 lint error messages can be customized to support integration with a wide variety of editors and IDEs
  • 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. (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 (TM) (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
Pricing

A one user, non-floating license for one computer workstation is $998

On your mainframe, server or local area network at one location,

  • To license one concurrent user would cost $1998.
  • To license up to five concurrent users would cost $3000.
  • To license up to ten concurrent users would cost $6000.
  • Each additional user after 10 would be $500.

If you need FlexeLint? for more than one location, contact us with the number of users and number of locations you want to license, and we'll provide you with a quote.

FlawFind: Security-vulnerability Checker

!FlawFinder is a program that examines source code and reports possible security weaknesses (flaws) sorted by risk level.

Flawfinder works by using a built-in database of C/C++ functions with well-known problems, such as buffer overflow risks (e.g., strcpy(), strcat(), gets(), sprintf(), and the scanf() family), format string problems ([v][f]printf(), [v]snprintf(), and syslog()), race conditions (such as access(), chown(), chgrp(), chmod(), tmpfile(), tmpnam(), tempnam(), and mktemp()), potential shell metacharacter dangers (most of the exec() family, system(), popen()), and poor random number acquisition (such as random()). The good thing is that you don't have to create this database - it comes with the tool.

Flawfinder then takes the source code text, and matches the source code text against those names, while ignoring text inside comments and strings (except for flawfinder directives). Flawfinder also knows about gettext (a common library for internationalized programs), and will treat constant strings passed through gettext as though they were constant strings; this reduces the number of false hits in internationalized programs.

Flawfinder produces a list of hits (potential security flaws), sorted by risk; by default the riskiest hits are shown first. This risk level depends not only on the function, but on the values of the parameters of the function. For example, constant strings are often less risky than fully variable strings in many contexts. In some cases, flawfinder may be able to determine that the construct isn't risky at all, reducing false positives.

flawfinder is fundamentally a naive program; it doesn't even know about the data types of function parameters, and it certainly doesn't do control flow or data flow analysis.

OINK: Framework to Build your own Static Analysis Suite

Oink is a collaboration of C++ static analysis tools. The C/C++ front-end for Oink is Elsa by Scott McPeak?. Currently the main tool provided by Oink is CQual++, a polymorphic whole-program dataflow analysis for C++. CQual++ was inspired by Jeff Foster's Cqual tool and shares the backend solver with it.

Oink aims to be

  1. industrial-strength for immediate utility in finding bugs,
  2. extensible for ease in adding backends, and
  3. composable for ease in combining existing backends.

Oink computes both

  1. expression-level and type-level dataflow, and
  2. statement-level intra-procedural controlflow (by delegating to Elsa)

It easy to get started by using the two demo backends that print graphs of these flows. Oink also comes with a client of the dataflow analysis that does type qualifier inference: Cqual++, a C/C++ frontend for Cqual Whole-program analyses may be attempted using the linker imitator.

1997 Survey of C++ Static Analyzers

A First Look at C++ Program Analyzers by Scott Meyers and Martin Klaus

  • CodeCheck from Abraxas Software. CodeCheck is a standalone product that lets programmers use a C-like language to specify what kinds of program analysis should be performed. It comes with several predefined analysis programs, including some for computing program complexity metrics and for identifying unportable code.
  • !C++Expert from CenterLine? Software. Also a standalone product, !C++Expert performs static and dynamic analyses of C and C++ programs. Its static checks are drawn from Scott Meyers' Effective C++ and More Effective C++ (see References), and its diagnostics contain hypertext links to on-line versions of those books.
  • FlexeLint/PC-Lint from Gimpel Software. Another standalone product (the name is FlexeLint for Unix, PC-Lint for DOS, Windows, and OS/2), !lexeLint/PC-Lint is perhaps truest to the classic lint tradition. It can check for over 600 potential error conditions in C and C++ source code, including conditions that affect more than one translation unit or that require detailed dataflow analysis.
  • CodeAdvisor from Hewlett Packard. CodeAdvisor is a part of HP's SoftBench development environment. It comes able to enforce 23 predefined rules, but users may extend its capabilities by coding new analyses in C++ and linking them in. Source code information is stored in a database, so it is possible to perform checks that involve multiple translation units.
  • CodeWizard from ParaSoft. C!odeWizard is a standalone product designed to enforce a set of 24 rules selected from Effective C++.
  • !QA/C++ from Programming Research Ltd.. Another standalone product, !QA/C++ works in two phases. First, it examines C or C++ source code and stores the results in a database. Different Programming Research analysis tools may then be run against the database, and it is these tools that generate warning messages. There is no database API that lets programmers develop their own analyses.
  • The Apex C/C++ Development Environment from Rational Software. The Apex environment includes, among other capabilities, the ability to enforce 22 predefined rules for C and C++ programming.

Long term utility of static analyzers

Comments from Gregory P. Dubois-Felsmann

The BaBar experiment used Parasoft's "CodeWizard", a static-analysis predecessor to C++test, mostly in the period about ten through five years ago. We found it moderately useful in looking for common coding errors of the Scott Meyers "Effective C++" sort. I'm not familiar with their current tools at all.

We eventually dropped the use of CodeWizard as our superficial code quality increased over time and it appeared to have reached the point where we were spending more time trying to understand whether the remaining CodeWizard results were relevant than we spent on debugging real problems that CodeWizard might have prevented. Our focus shifted fairly dramatically once we reached production and run-time analysis tools (e.g., valgrind) became much more important to us. Our budget for commercial licensed software was also always under constant pressure.

My understanding was that qac++ would provide the _analysis_ but would not give any user access to its results - for which the GUI tool would still be needed. (They say they still have some vestigial line-mode results-study tools, but that they are phasing them out in favor of a Web interface.)

In BaBar we had had CodeWizard incorporated into our workflow in such a way that, for CodeWizard warnings with low false-positive rates, we created bug tickets against packages and/or automatically e-mailed the responsible developers.

We ended up with O(5M) LOC and O(1000) packages and it's hard to imagine static analysis on a software system of that magnitude being scalable without the ability to script the distribution of problem reports to developers.

C++ Dynamic Analysis Tools

Valgrind

valgrind's tool suite can automatically detect many memory management and threading bugs.

gcov/ggcov

gcov and (t)ggcov are tools for exploring test coverage data produced by gcc.

Comments From LSST Participants

Error: Macro AddComment(None) failed
Error: Insufficient privileges to AddComment