C/C++ analysis configuration


Overview

This section provides a detailed explanation of the various C/C++ related analysis configuration settings.

Analysis configuration settings are only exposed in the CAST Imaging UI when a first analysis of your application has been completed. Analysis settings are initially positioned according to the information discovered during the application onboarding/source code delivery process prior to the first analysis and these may not all be appropriate:

The initial analysis with these “discovered” settings may uncover missing headers or macros - if this is the case, then the project may use these features. In the majority of cases, however, you are likely only to encounter missing headers - this is a good indication that the source code files were forgotten and are not part of the source code delivery.

You should therefore check logs files post initial analysis and that these auto-determined settings are as required.

Settings

Development Environment

This option will always be set to Not Specified after the initial analysis. You can use this option to choose the development environment of your source code files - settings and options will then be automatically updated to match the selected Development Environment:

Visual C++ options

Choosing one of the Visual C++ option will mean that:

  • Inherited property sheets and standard Visual Studio macros are handled e.g.:
    • $(SolutionDir)
    • $(ProjectName)
    • $(InputName)
    • $(ProjectDir)
    • $(InputDir)
  • Only the release configuration is identified. If there is no release, then the first configuration is identified instead.

In addition, the following information will be identified and added to the various UI settings explained below:

  • Source files:
    • resolved in File System
    • matches pre-defined extensions
    • Not excluded from build
  • Compile directive
  • includes
  • macros
  • Visual Studio version & MFC usage
  • Console

Microsoft Visual Studio property sheets (.vsprops)

If a property sheet (.vsprops) is referenced from a Visual C++ project (.vcproj or .vcxproj) through the use of an environment variable, the property sheet may not be found during the discovery (which leads to badly configured analyses). Where an environment variable is used to reference a property sheet, you have several possibilities:

  • You can change the content of your C++ project so that it refers to the property sheet through a relative path, instead of through an Environment Variable. You can write a script to automate this process.
  • You can also ignore the missing property sheet during the discovery and modify the settings of the Analysis Units in the UI (i.e. add the include paths and macro definitions that would have been provided by the property sheet).

STL Support

This option allows you to choose how you want CAST to handle STL header files that are referenced in your source code.

Option Description
CAST emulator If STL header files are not available in your source code, select this option. This will then force the activation of a basic (i.e. non exhaustive) emulation of the most common STL headers (i.e. <string>, <vector>, <algorithm> etc.), thus avoiding an incomplete analysis or ambiguous/erroneous analysis results in most circumstances. This is the default option.
STL already in your Source Code Repository If STL header files are available in your source code, select this option. The STL header files will be analyzed along with the rest of your source code as normal.

Accept trigraphs

Select this option only if your code contains trigraphs. The analyzer will then interpret normalized character sequences as a single character - for example ??< will be interpreted as {. Note also that this option will also force the analyzer to accept digraphs.

Files to analyze

A list of the file extensions for the various parts of your C/C++ application. These file extensions are the default included in the current file filter and only files that match these file extensions will be taken into account during the analysis. You can manually update these file extensions if necessary.

Resources

The options Force Include File and Includes enable you to define additional paths for files that have been specified in the #include part of your project files. This is to ensure the correct resolution of links to files located in other directories. The analyzer will take into account the two include styles:

  • #include "fileA.h" - in this case, the analyzer will automatically search the path of the file that contains the #include, THEN the additional paths you have added and in the order specified.
  • #include <fileB.h> - in this case, the analyzer will search the additional paths first then, THEN the path of the the file that contains the #include.

The include paths are locations from where the included headers are found. These parameters should be identified automatically from the compilation directives. The files found in these include paths will be saved in the results. Thus, the only header paths you should mention here are the header paths of the custom applications.

Force Include File

This option is used to provide an extra header file which will be appended at the beginning of the preprocessed source, as if each source file were beginning with an #include directive on this file. It is useful in the following cases:

  • When you have a very large number of macros
  • When you have macros that need to be undefined (the GUI here can only define them)
  • When the code is using embedded ‘C’ on Sybase: contrary to Oracle, the Sybase embedded ‘C’ preprocessor adds some code at the beginning of the generated files. To compensate for this behaviour, you should add the following code in the header used for this option:
#include <sybhesql.h>
SQLCA sqlca;

You should indicate here the ExternFunctions.h. If you have several files to “force include”, all you need to do is to create an additional file that will include them (using the #include directive) and set this file as being “force included”.

Use the Add button to browse for the file you want to include. This file will contain the macros that you want the analyzer to take into account and must have the same structure as any C/C++ file (in other words, this file can contain #define orders to define macros, #include orders to include files, but also declare functions). It is possible to enter a simple filename (for example test.h) without an absolute path. In this case, the analyzer will search for the file as follows:

  • in the associated source code
  • then in any defined include path

Includes

Use this option to add any include paths that have not been automatically discovered. Any paths configured will be processed BEFORE any definitions associated to any selected IDE type in the Development Environment option.

Defining include paths for Microsoft compilers

Usually, if the Microsoft C++ compiler (i.e. Visual Studio) is installed on the analysis node, you just need to select the default “Microsoft VCxxxx” option (via the Development Environment option ). In some cases, however, you may also need to provide your include list yourself. The following rules should be followed:

  • Do not add more directories then required.
  • Do not select the “recursive” option for these paths.
  • Do not select a path such as C:\Program Files\Microsoft Visual Studio 10.0\VC\crt\src (this typically contains files that are reserved for Microsoft internal use and debugger).

In any of the three cases above, you will get an error message during the analysis such as:

#error directive encountered 'Use of C runtime library internal header file ... (file 'C:\PROGRAM FILES\MICROSOFT[...]\VC\CRT\SRC\CRTDEFS.H")'

Macros

Use this option to define any macros that are present in your source code and that need to be taken into account during the analysis:

  • Macro configured here will be processed AFTER any definitions associated to any selected IDE type in the Development Environment option.
  • If you include a file containing a list of macros, this file is included in each main file that is analyzed. In other words, and for illustrative purposes only, it would be as if each file selected for analysis started with #include "autoinclude.h" (where autoinclude.h is the name of the file selected in the Includes section described above). These macros are processed AFTER the macro definitions made in this section.
  • Most, if not all applications developed with Microsoft Visual C++ rely on a set of (standard or not) header files provided with the compiler (stdlib.h, windows.h etc.). These headers themselves heavily rely on various macros that are internally defined by the compiler. These macros are applied automatically to the source code following the selections made in the Development Environment option, as such there is no need to explicitly add them.

Dependencies

Dependencies are configured at Application level for each technology and are configured between individual Analysis Units/groups of Analysis Units. For the most part, CAST Imaging will create the required dependencies based on the application source code, however, you can customize this if required.

When a dependency is configured, during the analysis process source code corresponding to the Analysis Units in the Source column is scanned for references to objects in source code corresponding to the Analysis Units in the Target column. If any matches are found, then a link between the two objects will be created.

References (known as Dynamic Links) are traced using search strings which is less selective than parser based technology used for other links traced by the analyzer. This technology detects a reference to an object wherever its name is mentioned, regardless of the context in which this reference occurs. As a result, incorrect links may be traced if a string happens to match a given name even if it is not logically related to the corresponding object. As a result you may have to intervene to filter incorrect references.

Incorrect dependency settings may result in missing links - missing inter-technology dependencies - or in a large number of Dynamic Links that require validation. This can have a knock on effect on rule results and on transaction flow.

Analysis Units

This section lists all Analysis Units created either automatically based on the source code discovery process or manually. You should check that at least one Analysis Unit exists for the specific technology. Settings at Analysis Unit level can be modified independently of the parent Technology settings and any other Analysis Units if required - click the Analysis Unit to view its technology settings.

Technology settings at Analysis Unit level

Technology settings at Analysis Unit level are for the most part identical to those explained above. Some differences exist:

Settings - Use Microsoft Managed C++ extensions (CLR)

Select this option if your Source Code contains Microsoft Managed C++ extensions targeted at the Common Language Runtime (CLR).