CoverageScanner command line arguments

Syntax

cs<compiler> [<cs-options>] <compiler arguments>

coveragescanner --cs-compiler=<compiler> [<cs-options>] <compiler arguments>

coveragescanner --cs-profile=</path/to/filename.cspro> [<cs-options>] <compiler arguments>

Where:

• <compiler> is one of the compilers supported by Coco. Calling cs<compiler> results in a call of CoverageScanner as a wrapper of <compiler>.
• <cs-options> are one or more of the options that are described in the following sections.
• <compiler arguments> are all the other options. They are copied to the command line of the compiler when it is called by CoverageScanner.

For the use of --cs-compiler and --cs-profile see Miscellaneous.

Environment variables

CoverageScanner also reads options from the environment variable COVERAGESCANNER_ARGS. The options must be separated by spaces or tab characters (\t). If command line arguments are present and the variable COVERAGESCANNER_ARGS is also set, the command line options take precedence over the options in the environment variable.

This variable should only be set temporarily, e.g. in a script, because otherwise it would influence all builds.

The location of the temporary files that CoverageScanner generates can be changed by setting the environment variable SQUISHCOCO_TEMP_DIR to the path of another directory (see Location of the temporary files).

List of options

Coverage methods

For a description of the coverage methods, see Code coverage analysis.

• --cs-off: Disable all code coverage analysis. CoverageScanner then calls the compiler or linker unchanged.
• --cs-on: Enable code coverage analysis.

  This is the default if CoverageScanner is called directly or as a wrapper that starts with cs, like csgcc. If the wrapper has the same name as the program (e.g. gcc), code coverage is by default switched off.

• --cs-off=<pattern>: Disable all code coverage analysis when compiling a source with an absolute file name that matches the wildcard expression <pattern> or if the string <pattern> is identical to a command line argument. CoverageScanner then calls the compiler or linker unchanged.
• --cs-on=<pattern>: Enable all code coverage analysis when compiling a source with an absolute file name that matches the wildcard expression <pattern> or if the string <pattern> is identical to a command line argument.

  It is possible to have several --cs-on=<pattern> and --cs-off=<pattern> options. The last option that is matching decides whether code coverage analysis is enabled or disabled.

  Note: If several sources are compiled with the same compiler command (as it occurs with C#), disabling the coverage analysis for one source file with --cs-off=<pattern> will disable the analysis for all others.

• --cs-hit: Set the instrumentation mode to hit instrumentation. It then only matters whether an instrumentation point (a line, a condition or a block) was executed at least once, not how many times.
• --cs-count: Set the instrumentation mode to count instrumentation. (Default)

  With this mode, the number of times an instrumentation point is executed is counted.

• --cs-statement-block: Enable statement block coverage.
• --cs-decision: Enable statement block and decision coverage.
• --cs-condition: Enable statement block, decision and condition coverage. (Default)
• --cs-mcc: Enable Multiple condition coverage.
• --cs-mcdc: Enable MC/DC coverage.
• --cs-function: Enable function coverage. (Default)
• --cs-no-function: Disable function coverage instrumentation.
• --cs-line: Enable line coverage. (Default)

  If this option is set, decision and condition coverage are automatically enabled too and full instrumentation mode (--cs-full-instrumentation) is switched on.

• --cs-no-line: Disable line coverage. The other instrumentation modes that are automatically enabled by --cs-line are not disabled.

Summary of the effects of the options for coverage metrics

Most of the command line options that switch a certain coverage metric on also enable the data collection for other metrics. The following table shows which option enables which metrics.

Sometimes, the coverage measurements are also influenced by the option --cs-partial-instrumentation. For each of them, the table has two lines. The second line shows what happens when --cs-partial-instrumentation is present too. It is marked (+partial) in the table.

Fine-tuning of the instrumentation

• --cs-exclude-files-without-instrumentation: Exclude source files from the analysis which have no instrumented code.
• --cs-constexpr=option: option can be one of the following:
  • ignore: ignore the instrumentation of constexpr functions.
  • full: instrument all constexpr functions even if the target application does not include the generated code. This require a compiler supporting C++20 standard.
  • runtime: instrument only constexpr functions generated in the target application. This require a compiler supporting C++20 standard.
• --cs-no-exceptions: Do not instrument the catch block of a try...catch statement.
• --cs-no-assignments: Do not instrument Boolean expressions in assignments.
• --cs-no-command-line-analysis: Disable the compilation command line analysis.
• --cs-no-function-profiler: Disable Coco profiler.
• --cs-function-profiler=option: Enable Coco profiler. option can be one of the following:
  • all: Instrument all functions.
  • skip-trivial: Disable Coco profiler for function having only one statement.

  Note: Function profiling is currently only possible on some platforms.

• --cs-no-returns: Do not instrument Boolean expressions in return statements.
• --cs-combine-switch-cases: With this option, decision and condition coverage do not distinguish between case labels that lead to the same code. This means that in the following code, the cases i == 3 and i == 4 are not distinguished. If the option is not set, the two cases are counted separately.

  switch (i) {
      case 3:
      case 4:
         i = 0;
         break;
      ...
  }

  The option is valid for C/C++ and C#.

• --cs-partial-instrumentation: Suppression of redundant conditions. Setting this option also disables line coverage.

  The option influences the instrumentation of if statements without an else part, like

  if (cond) {
      i += 1;
  }

  Without the option, an invisible else branch is created and its coverage is measured too. If the option is set, this is no longer done and the coverage of the case in which cond is false is no longer measured. The instrumented code then becomes slightly smaller, which may be necessary on small embedded systems.

• --cs-full-instrumentation: No suppression of redundant conditions. (Enabled by default)
• --cs-boost: Specific handling of Boost library constructs. Currently this only means that the code behind the macro BOOST_FOREACH is not instrumented. (Enabled by default.)
• --cs-no-boost: No specific handling of Boost library constructs.
• --cs-qt4: No instrumentation for class members generated by moc for the Qt4, Qt5 and Qt6 libraries (Q_OBJECT, qt_metacall, qt_metacast, and so on). The code behind the macro Q_FOREACH stays also uninstrumented. Qt signals remain instrumented. (Enabled by default.)
• --cs-no-qt4: No specific handling of the Qt4 and Qt5 libraries.
• --cs-qt3: No instrumentation for class members generated by moc for the Qt3 library (Q_OBJECT, className, tr, and so on). Qt signals remain instrumented. (Enabled by default.)
• --cs-no-qt3: No specific handling of the Qt3 library.
• --cs-no-annotations: No extraction of annotations (comments and manual validations) from the source files.
• --cs-no-purecov-annotations: No extraction of purecov's annotations from the source files.
• --cs-disable-rvalue-support: Disable instrumentations using rvalues for compiler who does not support it.
• --cs-vs2010-lambda: Instrument the expression in the return statement of a lambda function.

  This brings a better support of lambda expression on Microsoft^® Visual Studio^® 2010. The option is only valid/needed for C++11 compilers and Visual Studio 2010. Coco handles lambda expressions properly in newer compilers.

• --cs-unique-ptr-namespace=<string>: Specific name space for std::unique_ptr template. If set to a string XXX, the implementation of the unique pointer is assumed to be in the class std::XXX::unique_ptr.
• --cs-unique-ptr-namespace-inline: Should be set if the standard C++ standard headers are using inline name spaces to declare the unique_ptr smart pointers.
• --cs-unique-ptr-namespace-not-inline: Opposite setting to --cs-unique-ptr-namespace-inline.
• --cs-shared-ptr-namespace=<string>: Specific name space for std::shared_ptr template. If set to a string XXX, the implementation of the shared pointer is assumed to be in the class std::XXX::shared_ptr.
• --cs-shared-ptr-namespace-inline: Should be set if the standard C++ standard headers are using inline name spaces to declare the smart shared_ptr pointers.
• --cs-shared-ptr-namespace-not-inline: Opposite setting to --cs-shared-ptr-namespace-inline.
• --cs-record-call=<function>: Declare <function> as the name of function to be recorded explicitly.

  This is necessary for functions that can throw an exception and break the execution flow. The execution of the function is recorded before its call. This permits to record the execution of the sequence of statement before and after this function separately.

  The option can be repeated; then several functions are declared.

• --cs-exit-function=<function>: Declare <function> as the name of an exit function.

  An exit function is a command that ends the control flow in a function, like a return statement or the call of the exit() function, or a function that always throws an exception. Any code directly after such a statement is then unreachable. With this option, it is possible to inform Coco that there are user-defined functions that have the same effect as exit().

  The option can be repeated; then several exit functions are declared.

• --cs-no-line-directive: Remove all #line directives from the code generated by the preprocessor for C++and C#.

  The preprocessor is called by the CoverageScanner before instrumenting a file; afterwards the original compiler is called. On some systems, compiling a file this way causes problems that do not occur when the compiler is called directly. Removing the #line statements then sometimes helps.

• --cs-counter-size=<int>: Size in bytes of the internal execution counters. Possible values are 1 (byte), 4 (32bit integer) or 8 (64bit integer). The counters are used inside the instrumented program to count the number of times an instrumentation point has been executed. Large internal counters prevent counter overflows, smaller counters may be necessary on small embedded systems to save space. The default value is 8.
• --cs-mcc-max=<size> | --cs-mcdc-max=<size>: Set the maximal size of the instrumentation tables that are used for Multiple Condition coverage or MC/DC. The default for <size> is 8000.

  For each decision, a truth table is generated under Multiple Condition coverage and MC/DC. <size> is the maximal number of lines in the table. If a decision requires a truth table that is longer than <size>, Coco falls back to condition coverage for that decision.

File and path inclusion

The following options specify which files are included in the code coverage. The options apply to files on the command line and to those that are specified on #include statements.

One can use wildcards and regular expressions. In contrast to the common usage, the * in wildcard expressions matches also the path separation characters. The syntax of regular expressions is described in Section (see Regular expressions).

Options accumulate. If more than one of the file inclusion/exclusion option is present, the last one that matches a given file determines whether it is included or excluded.

In the next options, name of the file in question is first converted to an absolute path.

• --cs-include-file-abs-wildcard=<pattern>: Include a file in the coverage analysis if its absolute path matches the wildcard expression <pattern>.
• --cs-exclude-file-abs-wildcard=<pattern>: Exclude a file from the coverage analysis if its absolute path matches the wildcard expression <pattern>.

  For example, --cs-exclude-file-abs-wildcard=*.h excludes all files with the extension .h.

• --cs-include-file-abs-regex=<pattern>: Include a file in the coverage analysis if its absolute path matches the regular expression <pattern>.
• --cs-exclude-file-abs-regex=<pattern>: Exclude a file from the coverage analysis if its absolute path matches the regular expression <pattern>.

  For example, --cs-exclude-file-abs-regex=^.*\.h$ excludes all files with the extension .h.

• --cs-include-path=<path>: Include all files in the directory <path> and its subdirectories in the coverage analysis. Wildcards or regular expressions cannot be used.

  For example, --cs-include-path=c:\include includes all files located in c:\include.

• --cs-exclude-path=<path>: Exclude all files in the directory <path> and its subdirectories from the coverage analysis. Wildcards or regular expressions cannot be used.

  For example, --cs-exclude-path=c:\include excludes all files located in c:\include and its subdirectories.

Examples for complex inclusion patterns:

• --cs-exclude-file-abs-wildcard=* --cs-include-file-abs-wildcard=*.cpp instruments only .cpp files.
• --cs-exclude-file-abs-wildcard=* --cs-include-file-abs-wildcard=*.cpp --cs-include-file-abs-wildcard=*.cxx instruments only .cpp and .cxx files.
• --cs-exclude-file-abs-wildcard=*\/3rdparty/* does not instrument any files from the directory 3rdparty.
• --cs-exclude-file-abs-wildcard=*\/3rdparty/* --cs-include-file-abs-wildcard=* instruments all files: The first filter rule has no effect.

Function inclusion

• --cs-include-function-wildcard=<string>: This command line option enables the user to include a function in the coverage analysis. The function name is specified using a wildcard expression, and for C++ code, must include the class name and namespace.

  For example, --cs-include-function-wildcard=C::* includes all members of the class C.

• --cs-exclude-function-wildcard=<string>: This command line option enables the user to exclude a function from the coverage analysis. The function name is specified using a wildcard expression, and for C++ code, must include the class name and namespace.

  For example, --cs-exclude-function-wildcard*::Get* excludes all members of any classes which starts with Get.

• --cs-include-function-regex=<string>: This command line option enables the user to include a function in the coverage analysis. The function name is specified using a regular expression, and for C++ code, must include the class name and namespace. See Regular Expressions for the syntax.
• --cs-exclude-function-regex=<string>: This command line option enables the user to exclude a function from the coverage analysis. The function name is specified using a regular expression, and for C++ code, must include the class name and namespace. See Regular Expressions for the syntax.

If more than one of these inclusion/exclusion options is present, the last one that matches a given function determines whether it is included or excluded.

The following option works independently of the previous ones:

• --cs-record-empty-functions: Enable instrumentation of functions with an empty body. (By default this is disabled.)

Debugging

• --cs-verbose-source-lines=<int>: Number of context lines around a source code lines that is printed in an error message.

  When as part of an error message or warning a source code is printed, then this flag sets the number of lines before an after it that are printed as its context. The default value is 3.

• --cs-verbose=<option>: Generate verbose debug messages. Possible options are:
  • cmd: During the build, CoverageScanner displays the command line arguments of the programs it executes. This includes the command line arguments of the compiler when it translates the instrumented source code.
  • build: During the build, the instrumentation by CoverageScanner is traced. This includes e.g. the information about which files are instrumented and which are excluded from instrumentation.

    This option automatically implies --cs-verbose=cmd.

  • api: When the instrumented program is run, the calls to the CoverageScanner library are traced.

  Note that it is possible to combine options as well. For example --cs-verbose=build --cs-verbose=api will produce a build log during instrumentation as well as a trace when the instrumented program is executed.

  By default, the output is written to stderr.

• --cs-verbose-file=<file>: Define the file used for generating a CoverageScanner log file when the instrumented program is run. This option has no effect when --cs-verbose=api is not used.
• --cs-keep-instrumentation-files: Do not delete temporary instrumentation files. They will be left under random names in the Coco temporary directory (see Location of the temporary files).
• --cs-warnings=<mode>: Instrumentation warning behavior:
  • none: Warnings will not be displayed.
  • display: Warnings will be displayed via stderr.
  • error: Warnings will trigger a compilation error.
• --cs-compilation-warnings=<mode>: Compilation warning behavior:
  • none: Warnings will not be displayed.
  • display: Warnings will be displayed via stderr.
  • error: Warnings will trigger a compilation error.
• --cs-annotation-warnings=<mode>: Source code annotations warning behavior:
  • none: Warnings will not be displayed.
  • display: Warnings will be displayed via stderr.
  • error: Warnings will trigger a compilation error.
• --cs-compiler-retry=<integer>: Number of times to retry a compilation. This might be necessary if the generated object might be temporary locked on some file systems.

Execution report

• --cs-output=<string>: Set the file name for the execution report. The extension .csexe is added automatically.

  By default, <string> has the value %F and CoverageScanner uses the application name without the path as name for the .csexe file.

  The value of <string> may be an absolute path, like /my/dir/%F. The directories in this path must already be present when the instrumented program runs, since CoverageScanner does not create them by default.

  Note: This behavior may change if the user provides their own output functions. See __coveragescanner_set_custom_io() and CoverageScanner.__coveragescanner_set_custom_io().

  Otherwise, <string> is interpreted as a path relative to the working directory at the time the program starts.

  <string> may contain several format specifiers. The values of the following specifiers are computed at compile time:

  • %T: Current local time as an integer. (Example: 163355 for 16h33 and 55s)
  • %D: Current local date as an integer. (Example: 20140130 for January 30, 2014)
  • %F: Application/library file name without path.
  • %A: Absolute application/library file name.
  • %B: Application/library file name without path and extension.
  • %P: Application/library file path.
  • %/: File path separator (on Unix a slash, /, and on Windows a backslash, \).

  The values of the following format specifiers are computed at runtime:

  • %c: Current working directory. The value is computed before the main() function is started. If the current working directory changes, this path remains identical.
  • %p: Process identifier. If for any reason it cannot be computed, %p will be replaced with an empty string.
  • %t: Current local time. If for any reason it cannot be computed, %t will be replaced with an empty string.
  • %d: Current local date. If for any reason it cannot be computed, %d will be replaced with an empty string.
  • <X>: Replace <X> with the content of the environment variable X.
• --cs-file-name-format-specifier: Enable the file format specifiers support.
• --cs-no-file-name-format-specifier: Disable the file format specifiers support.
• --cs-lock-csexe: Create a lock file which locks the access to the .csexe file during its generation. Useful if the AUT fork()s without exec()ing, and we wish to prevent the children from clobbering each other's coverage data.
• --cs-nolock-csexe: Inverse option to --cs-lock-csexe. The preprocessor output is transmitted to CoverageScanner through a temporary file.
• --cs-dump-on-signal=<signal>: Generate an execution report when a specific signal is received. The signal can be specified by a number from 1 to 63, or by the conventional signal name, like SIGINT, SIGTERM, etc. See Execution report generation with UNIX^® signals.
• --cs-dump-on-event=<string>: Generate an execution report when a specific Microsoft Windows event is received (see Execution report generation with Microsoft Windows events).
• --cs-trigger-function=<triggerfunction>: Save coverage data at the end of each call to <triggerfunction>. This switch may be repeated to handle more than one trigger function.

  <function> is specified according to the C++ convention. This means that A::foo stands for the function foo inside the A namespace or class. By default, the save function that is called after <triggerfunction> runs is __coveragescanner_save(), but it can be changed with the following switch.

• --cs-coverage-save-function=<savefunction>: Set the custom function that is inserted by --cs-trigger-function.

  <savefunction> must be a function without parameters, since it replaces __coveragescanner_save(). Coco automatically inserts a declaration for <savefunction> at the beginning of each source file. This makes it possible to define <savefunction> in a file that is compiled with --cs-custom-library-source (see Generated code).

Command line modification

• --cs-compiler-option=<option>: Add <option> to the end of the compiler command line when compiling the instrumented code. When code coverage is disabled, nothing happens. The option can be repeated if more than one option is needed.
• --cs-inject-arg=<sep><filter><sep><arg1><sep><arg2>: Inject a command line argument into the compiler/linker command line. <sep> is a character used as separator for an expression. <filter> is a regular expression which is applied to each argument. If one argument matches the filter, the injection is applied. If it starts with !, the regular expression is inverted. <arg1> and optionally <arg2> are the injected arguments.

  Example:

  • –cs-inject-arg=/.*/-g: inject -g to all command lines (.* matches every argument).
  • –cs-inject-arg=/-c/-DTEST=1: inject -DTEST=1 to all compilation command lines (lines containg the -c argument are "compilation commands")
  • –cs-inject-arg=/a.cpp/-o/a.o: inject 2 args: -o a.o to command lines that contain a.cpp
  • –cs-inject-arg=/!-c/-lfoo: inject -lfoo to all commands which are not compilation command lines.

  Click here for another example of its use.

• --cs-remove-arg=<sep><filter><sep><arg1><sep><arg2>: Remove a command line argument from the compiler/linker command line. <sep> is a character used as separator for an expression. <filter> is a regular expression which is used on each argument. If one of them matches the filter, the injection is applied. If it starts with !, the regular expression is inverted. <arg1> and optionally <arg2> are the arguments to be removed from the command line, and they can be regular expressions too.

  Example:

  • –cs-remove-arg=/.*/-g: remove -g from all command lines (.* matches every argument).
  • –cs-remove-arg=/-c/-DTEST=.*: remove -DTEST=1 or -DTEST=3 from compilation command lines (-c matches command lines which compile a source code).
  • –cs-remove-arg=/!-c/-O[0-3]: remove -O0 to -O3 from all commands which are not compilation command lines.
• --cs-libgen=<option>: Put an additional command line option to the compiler call which generates the code coverage library. The option can be repeated if more than one option is needed.

  The options are appended and become the content of $LIBGEN$, a variable that may occur in the replacement text for the profile option COMPILER_CMD (see Profile parameters for linker settings).

• --cs-library-after=<option>: Put the linker argument for the CoverageScanner library after a specified option.

  If used in the form --cs-library-after=-lmylib, the linker parameter for the CoverageScanner library will be inserted directly after the option -lmylib.

• --cs-library-at-start: Add the linker argument for the CoverageScanner library before all other command line options.
• --cs-library-at-end: Add the linker argument for the CoverageScanner library after all other command line options.

Generated code

• --cs-no-csharp-dynamic: If set, the C# dynamic type is not used in the instrumentation code generated by Coco.

  With the dynamic type, Coco can better handle Boolean expressions that contain non-Boolean objects with overloaded true and false functions. Dynamic types are however only available for Visual Studio 2010 and later; for earlier C# versions, this option is needed.

• --cs-csharp-dynamic: If set, the C# dynamic type is used in the instrumentation code generated by Coco.
• --cs-enable-coveragescanner-library-abs-wildcard=<string>: Enable the generation of the CoverageScanner library when the absolute file name of the generated binary matches the given wildcard expression.
• --cs-disable-coveragescanner-library-abs-wildcard=<string>: Disable the generation of the CoverageScanner library when the absolute file name of the generated binary matches the given wildcard expression.
• --cs-pointer-type=<string>: Type which can be used to cast a pointer to an integer. This might be int or long long depending of the target platform.
• --cs-memory-pool=<int>: Generate a CoverageScanner library which uses a memory pool of bytes instead of calling malloc()/free(). The size of the pool is <int> bytes. This option is useful only for operating systems which do not support dynamic memory allocation.
• --cs-memory-pool-code=<string>: Declaration code for the memory pool. This is optional and permits a custom declaration of the array containing the head used by the CoverageScanner library. The default implementation is a static array of character declared as follows: static char %S[%I]. The following placeholders are available:
  • %S: the symbol name for the custom heap.
  • %I: the heap size in bytes.
• --cs-memory-alloc-failure-function=<string>: C-function name which is called when a malloc() call fails. The prototype of the function should be void func(int size) and the function should not return. The parameter size is the requested memory size passed as argument of the malloc() function. This permits you to catch an out of memory issue of the CoverageScanner code through a custom function.
• --cs-link-instrumentation-tables: Chain all instrumentation tables at link time and not at run time. (This is the default.)

  The instrumentation tables are internal arrays generated by Coco which contain the counter variables for code coverage.

• --cs-register-instrumentation-tables: Chain all instrumentation tables at run time and not at link time. This option has an effect only on platforms for which the profile parameter INSTRUMENTATION_TABLES_LINKED_DURING_RUNTIME_SUPPORT (see Profile parameters for linker settings) has the value Yes.
• --cs-dotnet-exit-handler: Specific handling of .NET Core exit. This lets you save the execution report event if Environment.Exit is called.
• --cs-no-exit-handler-installation: Disable the automatic installation of the handler which saves the code coverage report. If this handler is not installed, no executions report will be generated when the application exits or when a custom signal or Windows event is received. Call __coveragescanner_install() to install the handler manually.
• --cs-minimal-api: With this command line option, a CoverageScanner API is generated that has fewer dependencies on external libraries than the default API. This may be necessary for embedded systems or when compiling a C# application with the command line switch /noconfig.
• --cs-custom-library-source=<file>: Compile <file> as an additional source. The object code for <file> is then linked to the code of the program.

  The option has an effect only for the instrumentation of C or C++ programs. The code in <file> must then be written in the same language.

  This is to include larger pieces of code into the instrumented code for a program without the need to change the sources of the program. The result is that code in the program can use the functions defined in <file>. But note that the new functions still need to be declared in the source files that use them.

  When <file> is used to define the <savefunction> that is set by --cs-coverage-save-function=<triggerfunction> (see Generated code), an explicit declaration is not necessary.

Miscellaneous

• --cs-compiler=<compiler>: This command option enables the user to select a compiler. This option does not normally need to be specified, due to the fact that the profile name is usually extracted from the command line name. cscl.exe implicitly selects the profile cl.cspro.

  For example, --cs-compiler=cl selects the profile cl.cspro.

• --cs-profile=</path/to/compilername.cspro>: This option sets the path of CoverageScanner profile. Using this option is not compatible with --cs-compiler.

  For example, --cs-profile=%SQUISHCOCO%\cl.cspro is equivalent to --cs-compiler=cl on Windows.

• --cs-architecture=<string>: Internal option to specify the target architecture. It sets the variable $ARCHITECTURE$ in the replacement text for the profile parameter PREPROCESSOR_CMD (see Profile parameters for preprocessor settings). The target architecture is also used to select alternate profile parameters (see CoverageScanner adaptation to a tool suite).
• --cs-parallel-build=<int>: Maximum number of concurrent code generation/compilation.
• --cs-cpp-ext=<list>: List of file extensions corresponding to C++ files (ex: .cpp,.cxx)
• --cs-c-ext=<list>: List of file extensions corresponding to C files (ex: .c)
• --cs-obj-ext=<list>: List of file extensions corresponding to object files (ex: .o,.obj)
• --cs-native-toolchain=<path>: Adds a directory to the search path of the native compiler. This command can be repeated. In this case the first one is the preferred location.
• --cs-option-file=<file>: Specify command line options from a file. The file may contain all valid CoverageScanner command line options and the command line options of the native tool. It must contain one argument per line. Leading and trailing spaces are removed and empty lines are ignored, but no other input processing is done. The option can be repeated.
• --cs-file-name-lower-case: Convert absolute file names to lower case. For backward compatibility with the version 4.1.
• --cs-no-pch: If set, precompiled headers are deactivated during the compilation.
• --cs-no-pch=<pattern>: Disable the precompiled header usage when compiling a source with an absolute file name that matches the wildcard expression <pattern> or if the string <pattern> is identical to a command line argument.
• --cs-no-cspch: If set, the files with the extension .cspch are not generated. This files are only used to enhance the compilation speed when using precompiled headers.
• --cs-squish: Enable the automatic Squish integration. (Default).
• --cs-no-squish: Disable the automatic Squish integration.

Preprocessor symbols as alternative to command line flags

Another way to control instrumentation is to define certain preprocessor symbols. This makes it possible to instrument code even if an IDE does not allow for additional command line options. One can for example define the symbol COVERAGESCANNER_COVERAGE_ON and this is equivalent to using the command line flag --cs-on. The symbols must be defined for each file that should be instrumented.

Regular expressions

Regular expressions are composed of items and combining operators. These can be:

• [...]: The brackets are used to define a set of characters. For example, [123] corresponds to the characters 1, 2 or 3. It is possible to define a range using the minus sign: [a-z] corresponds to all characters between a and z.
• [^...]: The caret defines a set of characters which should not match. For example, [^0-9] corresponds to any character except a digit.
• ?: The question mark after a regular expression item makes it optional. For example, ab? matches the string a or ab.
• +: The plus operator makes it possible to repeat the regular expression item. For example, ab+ matches every string ab...b.
• *: The star operator after a regular expression item signifies that the item is optional and can be repeated. For example, ab* matches every string ab...b and a.
• |: The pipe operator specifies an alternative. For example, a|b matches the character a or b.
• (...): The parenthesis groups expressions into sub-expressions. For example, (true)|(false) matches the string true or false.
• Regular Expression Items: The regular expression items are ASCII or magic characters. If a magic character needs to be used as an ASCII character, it has to be escaped with a backslash (\).