1. Introduction

1.1. About CodePeer

CodePeer is a source code analyzer that detects run-time and logic errors in Ada programs. Serving as an efficient and accurate code reviewer, in effect an expert assistant, CodePeer identifies constructs that are likely to lead to run-time errors such as buffer overflows, and it flags legal but suspect code typical of logic errors. Going well beyond the capabilities of typical static analysis tools, CodePeer also produces a detailed analysis of each subprogram, including pre- and postconditions.

CodePeer performs line-by-line testing in a fully automated way, and guarantees full path coverage. CodePeer finds defects early in the development process in conjunction with compilation when they are least costly to repair. In addition, it should be run on existing code to find latent defects before they become a problem in the field.

CodePeer is designed to support large systems and to detect a wide range of programming errors such as misuse of pointers, indexing out of arrays, buffer overflows (a prevalent source of security storage leaks), numeric overflows, numeric wraparounds, and improper use of Application Programming Interfaces (APIs). It pinpoints the root cause of each error down to the source line of code.

Even in the absence of explicit errors, CodePeer provides a thorough characterization of every component of the system in terms of its inputs, outputs, heap object creations, the preconditions on the inputs necessary to preclude run-time failures, the presumptions about return values of external subprograms, and the postconditions that characterize the range of outputs.

One of the strengths of CodePeer is its ability to analyze partial systems (e.g. libraries, incomplete set of sources, etc.) and make reasonable assumptions about functions that are not visible.

Another strength is the historical database maintained by CodePeer which allows users to ignore initial messages on an existing code base, and concentrate on new messages only detected as part of code changes.

In addition, CodePeer supports analysis of Ada code written for many different Ada compilers via the configuration of a project file, see Project File Setup.

An analysis may be launched from the command line for easy scripting and automation, or interactively using GPS. Output is produced as text, html, and via a database.

For information about how CodePeer works internally, see How does CodePeer Work?.

For a high level comparison between SPARK and CodePeer, see What’s the Difference between CodePeer and SPARK?.

To get started quickly with CodePeer, see the CodePeer tutorial via e.g. GPS Help ‣ CodePeer ‣ CodePeer Tutorial menu.

You will also find several examples via the Help ‣ CodePeer ‣ Examples menu in GPS.

1.2. How to Install CodePeer

We recommend to first install GPS (and optionally GNAT), and then install CodePeer under the same location. Alternatively, you can install the GNATbench plug-in for Eclipse instead of GPS, using the Eclipse installation mechanism.

If however you choose to install CodePeer in a different location, prefer refer to Installation under different locations.

1.2.1. Installation under Windows

If not already done, first run the GPS installer by e.g. double clicking on gps-19.1-x86_64-windows-bin.exe and follow the instructions.

Then similarly run the CodePeer installer, by e.g. double clicking on codepeer-19.1-x86_64-windows-bin.exe.

You should have sufficient rights for installing the package (administrator or normal rights depending on whether it is installed for all users or a single user).

Be sure to change the default location so that both GPS and CodePeer are installed under the same location of your choice.

1.2.2. Installation under GNU/Linux

If not already done, you need to extract and install the GPS compressed tarball and then run the install, e.g:

$ gzip -dc gps-19.1-x86_64-linux-bin.tar.gz | tar xf -
$ cd gps-19.1-x86_64-linux-bin
$ ./doinstall

Then follow the instructions displayed.

Then do the same with the codepeer tarball, e.g.:

$ gzip -dc codepeer-19.1-x86_64-linux-bin.tar.gz | tar xf -
$ cd codepeer-19.1-x86_64-linux-bin
$ ./doinstall

Be sure to specify the same location chosen during the GPS installation.

Note that you need to have sufficient rights for installing the package at the chosen location (e.g. root rights for installing under /opt/codepeer).

1.2.3. Installation under different locations

If you decide to install GPS and CodePeer under different locations, you should also modify or set the following environment variable:

  • GPR_PROJECT_PATH, in order to analyze with CodePeer projects that depend on library projects installed with GNAT, such as GNATcoll;

On Windows, you can edit the value of GPR_PROJECT_PATH under the Environment Variables panel, and add to it the value of <GNAT install dir>\lib\gnat;<GNAT install dir>\share\gpr.

On Unix you can use, for instance, using Bourne-shell-compatible syntax:

$ GPR_PROJECT_PATH=<GNAT install dir>/lib/gnat:<GNAT install dir>/share/gpr:$GPR_PROJECT_PATH

or with C shell:

$ setenv GPR_PROJECT_PATH <GNAT install dir>/lib/gnat:<GNAT install dir>/share/gpr:$GPR_PROJECT_PATH

1.3. System Requirements

Static error detection is complex and time consuming, so CodePeer will benefit from all the speed (CPU) and memory (RAM) that can be made available.

Even though any machine can run CodePeer these days, in order to get the most out of CodePeer, you will need to use a powerful machine with many cores and memory. A comfortable setup for a CodePeer server is a machine with 24 physical cores or more, with at least 48GB of memory (2GB per core) running a 64bits CodePeer. Using many cores will allow you to perform many runs in a short time.

For a desktop machine a minimum of 4 cores is recommended (8 preferred) with at least 2GB per core (so 8 to 16GB).

Note that using local and fast drives will also make a difference in terms of analysis and storing results. Network drives such as NFS, SMB or worse, configuration management filesystems (such as ClearCase dynamic views) should be avoided as much as possible and will produce very degraded performance (typically 2 to 3 times slower than on local fast drives). If such slow drives cannot be avoided for accessing the source code then you should at least configure your project file so that the results of CodePeer analysis are stored on a drive local to the machine performing the run. This can be achieved by setting either the Object_Dir project attribute, or via the Output_Directory and Database_Directory attributes, see Project Attributes for more details.

Finally, if you want to perform a global analysis using the -level max switch (complete analysis with no partitioning) you will need at least 12 GB plus 1 GB of RAM per 10K SLOC of code. In other words, in order to analyze 200K SLOC of code at -level max, you will need a 64bits configuration with at least 32 GB of RAM. Note that these numbers will vary depending on the complexity of your code.

1.4. Basic Project File Setup

1.4.1. Basic Setup

If you want to get started quickly with CodePeer and start performing runs at the lowest level (level 0, the default), then you can create a project file that will look like:

project My_Project is
   for Source_Dirs use ("./**");
   for Target use "codepeer";

   package CodePeer is
      for Switches use ("--simple-project");
   end CodePeer;
end My_Project;

saved in a file called my_project.gpr. Note that you can specify as many source directories as needed as part of the Source_Dirs setting. The special syntax dir/** represents the directory dir and all its subdirectories recursively (in the above example, the current directory represented by . and all its subdirectories).

You can use the project wizard from GPS to create a project file interactively, via the menu File ‣ New Project.... In the dialog, see in particular the default option (Single Project).

Note that this basic setup will only be sufficient when running CodePer at level 0. At level 1 and above, you will need to configure your project file in more detail, as explained in Project File Setup, and remove the --simple-project switch which is only suitable for analysis at level 0.

For more details on CodePeer levels, see CodePeer Levels.

1.4.2. Configuring IDEs to Drive Tools

Note: if you are using GPS also with the GNAT compiler, you can skip this section.

If you are using CodePeer as a standalone tool without a GNAT installation then you will need to add the following section to your project file:

for Target use "codepeer";

1.5. Project File Setup

1.5.1. Project File Creation

If not already done, you need to create a GNAT project file (.gpr), as documented in the GPRbuild User’s Guide, section GNAT Project Manager. See also Project Attributes for optional project attributes to specify the output directories and other CodePeer switches in the project file directly.

You can use the project wizard from GPS to create a project file interactively, via the menu File ‣ New Project.... In the dialog, see in particular the default option (Single Project).

1.5.2. Naming Scheme

If you are using a different naming scheme (than the default .ads/ .adb) for your source files, you will need to use either the simple approach designed in Simple Non Default Naming Scheme if it suits your project, or the more complex approach described in Arbitrary Naming Scheme. Simple Non Default Naming Scheme

When using the GPS project wizard, you can select a number of predefined simple naming schemes which correspond to the default used by some Ada compilers. GPS will generate a package Naming in your project file corresponding to this scheme. You can also write such Naming manually.

For instance:

project My_Project is

   package Naming is
      for Spec_Suffix ("Ada") use ".1.ada";
      for Body_Suffix ("Ada") use ".2.ada";
      for Separate_Suffix use ".2.ada";
      for Dot_Replacement use ".";
   end Naming;
end My_Project;


project My_Project is

   package Naming is
      for Spec_Suffix ("ada") use "_.ada";
      for Body_Suffix ("ada") use ".ada";
      for Separate_Suffix use ".ada";
      for Dot_Replacement use "__";
   end Naming;
end My_Project;

This approach applies only to projects where a single and consistent naming scheme is used for all source files. If multiple or inconsistent naming schemes are used, then you will need to follow Arbitrary Naming Scheme instead.

1.5.3. Ada Language Version

By default CodePeer assumes sources are using the Ada 2012 language (latest standard). If your sources are using an older version of Ada, then you will need to add the following to your project file:

package CodePeer is
   for Switches use ("-gnat95");
end Builder;

The switches corresponding to the various Ada versions are: -gnat83, -gnat95, -gnat2005, -gnat2012.

Note that some Ada 95 compilers support the overriding keyword but no other Ada 2005 features. In order to analyze such code, you need to add the -gnatd.D switch in your project file, in addition to the -gnat95 switch:

package CodePeer is
   for Switches use ("-gnat95", "-gnatd.D");
end CodePeer;

1.5.4. 32bits Mode

By default CodePeer assumes that the compilation target is the same as the host on which it is run. This is often a sufficient default, suitable for most 32 and 64bits Ada compilers, although one typical case where this is not sufficient is when using CodePeer in 64bits mode, and analyzing code designed for 32bits architectures. In this case, you can run CodePeer with the -32bits switch so that CodePeer will analyze the code assuming the same architecture, but in 32bits mode instead of 64bits. You can use this switch either from the command line, or specify it in your project file:

package CodePeer is
   for Switches use ("-32bits");
end CodePeer;

See also Target Configuration File for advanced configuration of the target.

1.5.5. Representation Clauses

If CodePeer generates errors during the SCIL generation related to Ada representation clauses, a simple way to address these errors is to add the -gnatI compiler switch to your project file:

package CodePeer is
   for Switches use ("-gnatI");
end CodePeer;

-gnatI instructs CodePeer to ignore representation clauses, as if they had been stripped from the source code.

1.5.6. Use of Predefined Ada Packages

The predefined Ada packages (in particular, children of Ada, System, and Interfaces) come packaged with CodePeer, so you do not need and should not include in your project file alternative predefined Ada source packages, such as are provided by some Ada compilers, since these predefined packages may contain nonportable constructs that CodePeer may not recognize.

For compiler specific packages, see Use of Compiler Specific Packages for accessing some of these. If this isn’t sufficient, you will need to include at least the package specs from your target compiler as part of your project file as for any other source file.

1.5.7. Use of Compiler Specific Packages

If your Ada code base is making use of compiler specific packages, CodePeer provides some of these packages preinstalled under install/share/gpr and accessible as preconfigured project files.

In particular you will find the following project files:

  • aa.gpr: ApexAda specific packages.
  • am.gpr: AdaMulti and AdaMagic specific packages.
  • oa.gpr: ObjectAda specific packages.
  • vads.gpr: VADS specific packages.
  • xgc.gpr: XGC specific packages.

To use these project files, add for example the following line to your project file (adjust the name of the file as needed):

with "am";

project My_Project is
   --  other declarations...
end My_Project;

If some compiler specific packages are missing, do not hesitate to contact your CodePeer support.

1.5.8. Project Attributes

In addition to the project attributes described in the GNAT User’s Guide and mentioned earlier in this chapter (e.g. Source_Dirs, Naming and IDE packages, ...), the following optional project attributes are available in the CodePeer package:

  • Additional_Patterns

    Extra MessagePatterns.xml file to use in addition to the default patterns file. this can be either a path relative to the project’s directory, or an absolute path.

  • CWE

    Enables displaying of relevant CWEs for messages in GPS and in text/CSV output (not in HTML reports). Possible values are “true” or “false”, e.g.:

    package CodePeer is
       for CWE use "true";
    end CodePeer;
  • Database_Directory

    CodePeer database directory to use for this project. By default, the database directory is codepeer/<project>.db. If you specify a relative directory, this directory is relative to the location of the project file itself.

  • Excluded_Source_Files

    List of project source file (as base names) which should be excluded from CodePeer’s analysis.

  • File_Patterns

    This attribute is only relevant when running CodePeer at level 0. At higher levels, you need a more complete project file setup with an explicit naming scheme, as explained in Naming Scheme.

    When using --simple-project at level 0, source files are found using a default set of file extensions: .ada, .ads, .adb, .spc, .bdy.

    If you want to override these default file extensions, you can add this attribute File_Patterns which includes a list of file patterns where you can specify the following meta characters:

    * matches any string of 0 or more characters
    ? matches any character
    [list of chars] matches any character listed
    [char-char] matches any character in given range
    [^list of chars] matches any character not listed

    These patterns are case insensitive.

    For example:

    for File_Patterns use ("*.a", "*.ad[asb]", "[a-z][0-9]*.a?");

    specifies that all sources ending with .a, .ada, .ads, .adb as well as all sources starting with a letter, followed by a digit and ending with .a and one last character will be analyzed.

  • Message_Patterns

    Alternate MessagePatterns.xml file to use for this project.

  • Output_Directory

    CodePeer output directory to use for this project. By default, the output directory is codepeer/<project>.output. If you specify a relative directory, this directory is relative to the location of the project file itself.

  • Server_URL

    URL to access the CodePeer server for analysis information and messages review. When not specified, it means that all operations are local.

  • Switches

    List of additional switches always used for this project.

Here is an example of a project file using some of these attributes:

project Prj1 is

   package CodePeer is
      for Excluded_Source_Files use ("file1.ads", "file2.adb");
      for Output_Directory use "project1.output";
      for Database_Directory use "/work/project1.db";
      for Switches use ("-level", "2");
      for Additional_Patterns use "ExtraMessagePatterns.xml";
      for CWE use "true";
   end CodePeer;
end Prj1;

1.5.9. Project File Example

Here is a complete example of a project file containing two directories with Ada 95 source files using an alternate naming scheme, to be used without GNAT and ignoring the representation clauses:

project My_Project is
   for Target use "codepeer";

   for Source_Dirs use ("sources/src1", "sources/src2");

   package CodePeer is
      for Switches use ("-gnat95", "-level", "2");
   end CodePeer;

   package Naming is
      for Spec_Suffix ("Ada") use ".1.ada";
      for Body_Suffix ("Ada") use ".2.ada";
      for Separate_Suffix use ".2.ada";
      for Dot_Replacement use ".";
   end Naming;
end My_Project;

1.6. Advanced Project File Setup

When configuring CodePeer to analyze Ada code that has not been used with GNAT before, it is often necessary to follow some of the advices listed in this section.

1.6.1. Arbitrary Naming Scheme

If you are using a more complex naming scheme (e.g. files with mixed casing, no automatic mapping between unit names and file names, use of multiple units in a single file, etc...) then you have three options:

  • Use the File ‣ Project ‣ Add Complex File Naming Conventions... menu in GPS and follow the dialog. This will call the underlying command line tool codepeer-gnatname and modify the project file for you. See the GPS documentation for more details.

  • Use the codepeer-gnatname tool to generate the custom naming scheme automatically

    To create complex project files automatically from an existing directory structure, you can use the codepeer-gnatname utility from the command line. Here is a typical usage of codepeer-gnatname:

    codepeer-gnatname -Pmy_project "-d./**" "*.ad?" "*.spc" "*.bdy"

    which will create (or update) a project file called my_project.gpr listing all the Ada source files found under the current directory and all its subdirectories whose name follow the given patterns (all files ending with .ad<any character>, all files ending with .spc and all files ending with .bdy).

    Note that codepeer-gnatname requires a writable temporary directory. If the project file generated is empty, you might need to set the environment variable TMPDIR to a writable directory.

    See the gnatname documentation in the GNAT User’s Guide for more details on how to use gnatname.

  • Use the codepeer-gnatchop tool

    Alternatively, you can preprocess your sources to generate .ads/.adb files by running codepeer-gnatchop on all your Ada sources and use a simple project file on the generated sources, for instance under Linux:

    cd <root source directory>
    mkdir sources
    find . -name sources -prune -o -name '*.ad?' -exec codepeer-gnatchop {} sources \;

    This command will take all files ending with .ad<any character> under the current source tree, and generate a corresponding .ads/.adb file under a new directory called sources. You can then use in your project file:

    for Source_Dirs use ("sources");

1.6.2. Target Configuration File

Usually, using either the default settings, the -32bits or the -gnatI switch is sufficient to analyze code for most targets.

If you need to configure CodePeer so that it has a deeper knowledge and understanding of the target compiler, and in particular setting target dependent values such as endianness or sizes and alignments of standard types, then you might need to add the following to your project file:

package CodePeer is
   for Switches use ("-gnateT=" & project'Project_Dir & "/target.atp");
end CodePeer;

where target.atp is a file stored here in the same directory as the project file my_project.gpr, which contains the target parametrization. This file can be generated by calling the GNAT compiler for your target with the switch -gnatet=target.atp. The format of this file is described in the GNAT User’s Guide as part of the -gnateT switch description.

Here is an example of a configuration file for a bare board PowerPC 750 processor configured as big-endian:

Bits_BE                       1
Bits_Per_Unit                 8
Bits_Per_Word                32
Bytes_BE                      1
Char_Size                     8
Double_Float_Alignment        0
Double_Scalar_Alignment       0
Double_Size                  64
Float_Size                   32
Float_Words_BE                1
Int_Size                     32
Long_Double_Size             64
Long_Long_Size               64
Long_Size                    32
Maximum_Alignment            16
Max_Unaligned_Field          64
Pointer_Size                 32
Short_Enums                   0
Short_Size                   16
Strict_Alignment              1
System_Allocator_Alignment    8
Wchar_T_Size                 32
Words_BE                      1

float          6  I  32  32
double        15  I  64  64
long double   15  I  64  64

If your target compiler is not GNAT, or an old version of GNAT, then you can also build and run the small utility called generate_target which can be found under <codepeer install>/share/codepeer/target. See comments inside this file for instructions on how to use it.

Note that, depending on the Ada constructs you are using and the values specified in the target configuration file, some combinations will not be properly supported and will lead to errors during SCIL generation. In this case, consider using instead the -gnatI switch, or contact your CodePeer support for alternatives.

1.6.3. Using the GNAT Target Runtime Directory

If you are using GNAT as your target compiler and explicitly specify a runtime and target to use in your project, for instance:

for Target use "arm-eabi";
for Runtime ("Ada") use "ravenscar-sfp-stm32f4";

CodePeer will take such setting into account and will use the GNAT runtime directory, as long as your target compiler is found in your PATH environment variable. Note that you will need to use a matching version of GNAT and CodePeer (e.g. GNAT 18.2 and CodePeer 18.2).

The handling of runtimes of CodePeer is in fact unified with that of the GNAT compiler. For details, see “GNAT User’s Guide Supplement for Cross Platforms”, Section 3. If you specify a target, note that CodePeer may use additional configuration, see the section Target Configuration File.

If for some reason you do not have access to the GNAT compiler on the same machine as CodePeer (e.g. the GNAT cross compiler is installed on a different host than CodePeer) you will first need to copy the GNAT runtime directory in the CodePeer installation, under codepeer-prefix/libexec/codepeer/lib/gnat/.

For example, assuming you want to use a runtime called ravenscar-sfp-stm32f4, then first locate this runtime on the machine with the GNAT installation, e.g.:

arm-eabi-gnatls -v --RTS=ravenscar-sfp-stm32f4 | grep adalib

This command gives the path to <ravenscar-sfp-stm32f4 runtime>/adalib.

You then need to copy/transfer the <ravenscar-sfp-stm32f4 runtime> directory to the CodePeer installation, under codepeer-prefix/libexec/codepeer/lib/gnat/, for example using bash syntax:

scp -pr $(dirname $(arm-eabi-gnatls -v --RTS=ravenscar-sfp-stm32f4 | grep adalib)) \

1.6.4. Configuration of System Package (system.ads)

Some Ada compilers provide additional, nonportable definitions in the predefined package System which might lead to errors when CodePeer generates SCIL.

A solution to address this issue automatically is to use the pragma Extend_System in a pragma configuration file, either using one of the predefined GNAT extensions (e.g. Aux_Dec for the DEC Ada compiler or VADS for the VADS compiler, available via the project file vads.gpr as described in Use of Compiler Specific Packages), or by providing a customized s-auxcom.ads file.

For example, you can create a file called e.g. codepeer.adc located under the same directory where your project file is, which will contain:

pragma Extend_System (Aux_Dec);

or alternatively:

pragma Extend_System (Aux_VADS);

And configure your project file to take this file into account:

package Builder is
   for Global_Configuration_Pragmas use "codepeer.adc";
end Builder;

or if using Aux_VADS:

with "vads";
project My_Project is

   package Builder is
      for Global_Configuration_Pragmas use "codepeer.adc";
   end Builder;

end My_Project;

Similarly, if your target compiler provides additional definitions, you can manually create a s-auxcom.ads file containing these additional definitions, e.g.:

package System.Aux_Compiler is
   pragma Preelaborate;

   function To_Integer (Addr : Address) return Integer;
   function To_Address (Int  : Integer) return Address;

   No_Addr      : constant Address := Null_Address;
   Address_Zero : constant Address := Null_Address;

   Assertion_Error : exception;

end System.Aux_Compiler;

and then specify:

pragma Extend_System (Aux_Compiler);

in codepeer.adc.

See the GNAT Reference Manual for more details on Pragma Extend_System.

Also note that you should never include the compiler System package in your project file (either in your source file list or even in your source directories), as CodePeer needs to use its own provided system.ads.

1.6.5. Using Preprocessing

In order to enable the GNAT integrated preprocessor, you can use the -gnateD and -gnatep switches, e.g.:

package CodePeer is
   for Switches use ("-gnateDVAR1=xxx", "-gnateDVAR2=yyy");
end CodePeer;

See section Integrated Preprocessing in the GNAT User’s Guide for more details. See also the section Form of Input Text for gnatprep in chapter Preprocessing with gnatprep for more details on the syntax supported by the GNAT preprocessor.

1.6.6. Ignoring Pragmas

In some cases, nonportable pragmas are used across Ada technologies in an incompatible way, generating some spurious error messages when CodePeer analyzes these files. In order to address these issues, you can configure your project file to ignore a set of pragmas via the Ignore_Pragma pragma that you should place in a codepeer.adc file as explained in Configuration of System Package (system.ads). For example, if you want to ignore pragmas called Import_Procedure and Import_Function you can put in your codepeer.adc:

pragma Ignore_Pragma (Import_Procedure);
pragma Ignore_Pragma (Import_Function);

Similarly if you want to ignore pragma Global:

pragma Ignore_Pragma (Global);

If not already done, you need configure your project file to take this file into account:

package Builder is
   for Global_Configuration_Pragmas use "codepeer.adc";
end Builder;

1.6.7. Providing Stubs for Missing Generic Bodies

CodePeer will ignore missing bodies and will make reasonable presumptions about calls to such unknown subprograms (see CodePeer Presumptions).

However it will generate an error when it encounters a generic package whose body is missing at instantiation time. In order to work around this error, you can provide a skeleton for the generic package via the codepeer-gnatstub utility, e.g.:

codepeer-gnatstub -Pmy_project generic_package.ads

will generate a file generic_package.adb which can be used by CodePeer.

1.6.8. Detection of Floating Point Overflow

CodePeer assumes that floating point operations are carried out in single precision (binary32) or double precision (binary64) as defined in the IEEE-754 standard for floating point arithmetic. You should make sure that this is the case on your platform. For example, on x86 platforms, by default some intermediate computations may be carried out in extended precision, leading to unexpected results. With GNAT, you can specify the use of SSE arithmetic by using the compilation switches “-msse2 -mfpmath=sse” which cause all arithmetic to be done using the SSE instruction set which only provides 32-bit and 64-bit IEEE types, and does not provide extended precision. SSE arithmetic is also more efficient. Note that the ABI allows free mixing of units using the two types of floating-point, so it is not necessary to force all units in a program to use SSE arithmetic.

CodePeer considers the floating point values which represent positive, negative infinity or NaN as invalid, and it checks that such values cannot occur.

By default, CodePeer will only detect potential overflows on floating point operations on constrained floating point types (user floating point types with explicit ranges) and not on unconstrained types (e.g. predefined float types) unless you specify -level max where overflows are checked on all float types.

You can also ask CodePeer to check for possible floating point overflows on unconstrained types at any level (which will then lead to infinite values) via the -gnateF compiler switch, e.g.:

package CodePeer is
   for Switches use ("-gnateF");
end CodePeer;

1.6.9. CodePeer Specific Project Settings

If you are using project files also to build with GNAT and need to use e.g. different builder switches between GNAT builds and CodePeer analysis, you can then use a scenario variable to differentiate the two modes in your project file:

type Build_Type is ("Debug", "Production", "CodePeer");
Build : Build_Type := External ("Build", "Debug");

package Builder is
   case Build is
      when "CodePeer" =>
         for Global_Compilation_Switches ("Ada") use ("-gnatI");
         -- -gnatI is only relevant for CodePeer
      when others =>
         for Global_Compilation_Switches ("Ada") use ("-O", "-g");
         -- Switches only relevant when building
   end case;
end Builder;

and run codepeer with the -XBuild=CodePeer switch.

1.6.10. Ignoring Source File Timestamp Mismatch

If your environment changes the timestamps of your source files between CodePeer runs (without changing the source file contents), then in order to minimize the regeneration of SCIL files you can specify the -m switch in the Builder package of your project file, so that checksums rather than timestamps should be used for determining whether source files have changed since the previous run:

package Builder is
   for Switches ("Ada") use ("-m");
end Builder;

1.6.11. Ignoring Exception Handlers

By default CodePeer tries to take exception handlers into account in its analysis, although by doing so this can lead to a loss of precision in the detection of possible (or certain) run-time errors. If you want CodePeer to analyze the code by completely ignoring exception handlers (behave as if the exception handlers were stripped from the code) then you can add the -gnatd.x switch, e.g.:

package CodePeer is
   for Switches use ("-gnatd.x");
end CodePeer;

1.6.12. Handling Enumeration Representation Clauses

Even without -gnatI, CodePeer by default ignores enumeration representation clauses, to reduce the various implicit representation transformations required by such clauses, which can produce confusing output. If your application uses Enum_Rep, Enum_Val, or Unchecked_Conversion to manipulate the underlying codes specified by an enumeration representation clause, then you may want to override this CodePeer default by using the compiler switch -gnatd.I. This will cause CodePeer to obey the enumeration representation clause and ensure that Enum_Rep, Enum_Val, and Unchecked_Conversion are interpreted correctly for this enumeration type. This switch can be added to your project file, as follows:

package CodePeer is
   for Switches use ("-gnatd.I");
end CodePeer;