wiki:CppCodingStandardCheckerReview:
Last modified 10 years ago Last modified on 01/20/2009 07:02:24 PM

From: CodeStandards

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.

Pass/Fail? based on 'Quality Metric' during Build

Statement of need:
For structural and syntactic analysis of a source module, we will embed the the selected tool's 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.

Abraxis Software CodeCheck

Abraxas Software CodeCheck

Codecheck has the best price of the tools providing user customized coding standards compliance checking. Installation is also very hands on. There is a demo version which 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 sometimes pedantic 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.

A brief review provided by Jon Myers:

I have been in contact with Parasoft, they provide a small demo of their C++ analysis product through a Flash presentation: Parasoft C++test - Demonstration

  • Parasoft supports automated unit test generation.
  • 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.

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.

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.

....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.

Apart from this it appears to be hard to instrument tools like 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 the tool>. 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 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 PC-Lint (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++.
  • 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.

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

Add comment