Chapter 16 Reactis for C Plugin

The base Reactis product treats S-Functions and Stateflow custom C code as black boxes. Models containing such C code can be processed, but the C source code is inaccessible. Hence, there is no way to perform basic debugging operations such as single-stepping, viewing variable values, setting breakpoints, or browsing the source code during simulation. Furthermore, targets cannot be created within the C source code when generating tests. Reactis for C Plugin integrates seamlessly with Reactis to offer white-box testing and validation of the C-code portions of models (S-Functions and C code called from Stateflow). Together, Reactis and Reactis for C Plugin automate the generation of test data from, and validation of models constructed with Simulink, Stateflow, and C code.

A separate license is required to use the Reactis for C Plugin. If your organization does not yet own such a license please contact sales@reactive-systems.com to inquire about purchase options or to obtain a demo license for the product. Reactis for C Plugin requires base Reactis to run.

16.1 Quick Start

In the main Reactis window, select File -> Settings... and then display the Reactis for C tab. Make sure the Enable white-box analysis of C code check-box is selected.
To subject an S-Function to white-box analysis, do the following:
1. Right-click on the S-Function in the main Reactis panel and select Assign RSM File
2. Accept the default file name
3. Click Yes to create a new .rsm file
4. Add the C source files that implement the S-Function using the dialog.
Stateflow custom C code will be processed automatically when Reactis for C Plugin is enabled. No .rsm file is necessary.
Navigate to an S-Function in the hierarchy panel to display the C code for the S-Function. C code called from Stateflow will be listed at the bottom of the hierarchy panel under C Libraries -> Library: Stateflow User Sources.
The C code can be observed from Simulator and targets within the C code will be used by Tester to generate test suites that aim to maximize coverage of the C code.
Selecting Edit -> C Code will bring up the C code tab in the Info File Editor. This dialog displays the locations of all C components in the model. From here .rsm files can be added, edited or removed by right-clicking. See section 16.5 for more details.

16.2 Configuring Reactis for C

Figure 16.1: The Settings dialog with tab “Reactis for C” selected.

Figure 16.1 shows the Reactis for C Plugin tab of the Reactis settings dialog. Within this menu, the behavior of Reactis for C Plugin can be configured. The purpose of each menu item is as follows:

1. Enable white-box analysis of C code.

Enable or disable Reactis for C Plugin features.

2. On signed integer overflow.

This item determines the behavior of the C-plugin when overflow occurs during a signed integer computation. The effect of integer overflows outside of the C-plugin are not affected. There are two possible settings:

Produce error.: Stop execution and generate an error message.
Wrap over.: Emulate typical C runtime behavior and accept the hardware-produced result.

Integer overflows are discussed in more detail in Section 16.11.

3. On overflow during conversion from unsigned to signed integer.

This item determines the behavior of the C-plugin when an overflow occurs while converting an unsigned integer to a signed integer. There are three possible settings:

Produce error.: Stop execution and generate an error message.
Wrap over.: Emulate typical C runtime behavior and accept the hardware-produced result.
Inherit from “On signed integer overflow.”: Behave according to the setting of On signed integer overflow.

Integer conversions are discussed in more detail in Section 16.11.

4. On overflow during conversion from floating-point to unsigned integer.

This item determines the behavior of the C-plugin when an overflow occurs while converting a floating-point value to an unsigned integer. There are three possible settings:

Produce error.: Stop execution and generate an error message.
Wrap over.: Emulate typical C runtime behavior and accept the hardware-produced result.
Inherit from “On signed integer overflow.”: Behave according to the setting of On signed integer overflow.

Integer conversions are discussed in more detail in Section 16.11.

5. On invalid pointer creation.

This item determines what happens when a pointer expression yields an invalid address. There are three possible settings:

Produce error.: Stop execution and generate an error message.
Produce warning.: Generate a warning message and allow execution to continue.
Do nothing.: Ignore the invalid pointer. An error will occur if the pointer is used to access memory (which might never happen).

Details on the use of this option are provided in Section 16.12.1.

6. Display line numbers.

Toggle the display of line numbers in the main Reactis panel when displaying C source files. The Background Color button allows you to select the background color of screen region where the line numbers are displayed.

7. Display line grid.

Toggle the highlighting of every other line a different color. The Background Color button allows you to select which color is used.

8. Highlight comments.

Toggle the highlighting of comments within C source code. The Text Color button allows you to select the color of comment text.

9. Highlight inactive code.

Toggle the highlighting of code which has been disabled by preprocessor directives such as #ifdef. The Text Color button allows you to select the color of inactive code text.

10. S-Function source code coverage tracking.

This menu item configures the global setting for tracking coverage within the C code in S-Functions. This setting may be overridden for an individual S-Function within the .rsm file for the S-Function. The supported settings are:

Off.: Turn off coverage tracking within S-Functions.
Cumulative.: When there are multiple instances of the same S-Function in a model, track coverage cumulatively for all instances.
Separate.: When there are multiple instances of the same S-Function in a model, track coverage separately for the instances.

11. Create and use cache files for C code.

In order to analyze C code, Reactis for C Plugin must convert the source file into a Reactis object file (.rso file). Enabling this feature causes .rso files to be stored on disk (in the folder where the C code resides). Subsequently, a C source file will only be recompiled if the C source file is modified, or if a new version of Reactis is installed.

12. Source File Editor.

This allows you to specify an external editor that can be launched from Reactis to edit C source files.

16.3 S-Function C Code

Simulink does not require you to specify the C source files that implement an S-Function; instead only a name is given. For white-box testing, Reactis for C Plugin requires the C source files that implement an S-Function as well as the source files for any libraries referenced by the S-Function. Since the .mdl file does not include this information, Reactis for C Plugin has a mechanism for listing the C source files which comprise an S-Function. This mechanism is described in the rest of this section.

The collection of C source files that implement an S-Function is specified using a Reactis Make File (.rsm file), which is created and modified by the simple editor shown in Figure 16.2. An .rsm file is created to specify how Reactis for C Plugin should compile the S-Function. Additionally, a separate .rsm file is constructed for each library referenced by the S-Function. The .rsm files for the S-Function and any libraries referenced by the S-Function are defined in the same way. In the following discussion we denote the library compiled from an .rsm file as the library under construction (LUC).

The following sections appear within the .rsm file editor window:

1. Source Files.

The C source files that implement the LUC. These files may be expressed as either absolute or relative pathnames. See Section 16.3.1 for more details.

2. Libraries.

The .rsm files for any libraries referenced by the C code in the Source Files section. Like source files, libraries may be expressed as either absolute or relative pathnames. See Section 16.3.1 for more details.

3. Include Directories.

The list of directories that should be searched for files targeted by #include directives within the Source Files section.

4. Defines.

A list of macro definitions which are to be defined at the start of compilation. Macros are defined using expressions of the form:

name=value, in which case instances of the identifier name will be replaced by value during preprocessing, or
name, in which case name will be replaced by the literal 1 during preprocessing.

There is no mechanism provided to define macros which accept arguments or use macro operators such as stringification or token catenation. This is similar to the way the -D option works on most C compilers.

5. Export global symbols, prefix.

This check-box option facilitates using Reactis for C Plugin to build libraries that have wrappers generated by tools such as the GNU dllwrap utility. If this option is enabled, then the string specified in the text-box will be prefixed to the name of each global variable in the LUC. Since the S-Functions do not use such a wrapper, this option is disabled for S-Function .rsm files.

6. Coverage Tracking.

This menu specifies how coverage is tracked within the LUC. The coverage tracking options are as follows:

Inherited.: Use the global coverage tracking setting for the LUC. Note that the Inherited option is only available for S-Function .rsm files.
Off.: Turn off coverage tracking within the LUC.
Cumulative.: When there are multiple instances of the LUC in a model, track coverage cumulatively for all instances.
Separate.: When there are multiple instances of the LUC in a model, track coverage separately for the instances. Note that the Separate option is only available for S-Function .rsm files.

Figure 16.2: The Reactis Make File Editor is used to specify the C source files that make up an S-Function.

16.3.1 Pathnames

The path to each source file or library can be either relative or absolute. The location of a source file whose path is relative is determined by appending the relative path to the directory containing the .rsm file. For example, if the .rsm file C:\models\cruise\cruise.rsm references the source file ..\csrc\ramp.c, the absolute path to ramp.c will be C:\models\csrc\ramp.c. For convenience, the .rsm file editor provides buttons for converting paths from relative to absolute form, and vice-versa. To use one of these buttons, first select a source file or library by clicking on it, and then click on either the Relative or Absolute button to the right of the window containing the source file or library.

16.3.2 S-Function Requirements

All source code (for both an S-Function and any referenced libraries) must be available. In addition, all code must satisfy the requirements listed in Section 14.2.1.

16.4 Stateflow Custom C Code

Figure 16.3: A model containing Custom C Code before an .rsm file has been specified for ctest10_code_lib.a.

Reactis for C Plugin will automatically determine which C source files are called from Stateflow. This is possible because Stateflow requires you to specify the C source files in the Target Options dialog ¹ and stores the names of the files in the .mdl file for a model. Reactis for C Plugin automatically processes any custom C code files. User input is only required in cases where custom C code links to external libraries.

When a model is opened, the C files called from Stateflow will be listed at the bottom of the Reactis hierarchy panel in the C Libraries section, subsection Stateflow User Sources. This is illustrated in Figure 16.3. In this case, Reactis for C Plugin has determined that the file ctest10_code.c is called from Stateflow and has added it to the tree of model components, along with the library ctest10_code_lib.a. Note the error icon next to ctest10_code_lib.a. This icon indicates that user input is required to tell Reactis for C Plugin what sources belong to the library.

Figure 16.4: Reactis for C Plugin requesting information about the source code used to compile a library.

After selecting ctest10_code_lib.a, the message shown in Figure 16.4 is displayed. This message indicates that it will be necessary to create an .rsm file because the .mdl file does not list the sources used to build ctest10_code_lib.a. To specify the sources, right-click on the library model component (in this case ctest10_code_lib.a) and select Assign RSM File. A dialog window similar to the one in Figure 16.5 will appear. The process of creating the .rsm file is nearly the same as the process for creating S-Function .rsm files discussed in section 16.3. The only two differences are (1) that the editor window does not contain a library section, and (2) there is no coverage selection dialog. No coverage selection dialog is presented because coverage data in custom C code called from Stateflow is always collected cumulatively.

Figure 16.5: Creating an .rsm file for a library used by custom C code called from Stateflow.

16.4.1 Stateflow Custom Code Requirements

Reactis for C Plugin supports analysis of Stateflow custom code for which all C source code is available. The source files need not necessarily reside in the same directory as the model. Reactis will automatically search the directories in the Reactis path if a custom code source file or library is not found in the model directory. This behavior emulates the behavior of MATLAB . Regardless of what directory a library is found in, the .rsm file editor will start in the model directory when assigning the .rsm file associated with the library. If the .rsm file does not yet exist, the file system tree displayed as part of the open dialog window can be used to select a directory other than the model directory in which to create the .rsm file. For example, it could be desirable to create the .rsm file for a library which shared between models in the directory containing the source files used to build the library.

16.5 C Code Tab in the Info File Editor

Access to Reactis for C parameters is available from the Info File Editor. The C code tab displays a list of locations in the current model that reference C code (S-Functions and Stateflow custom code). This tab also gives the you ability to configure associated .rsm files.

Figure 16.6: Viewing C Code components in the Info File Editor.

Each of the window items labeled in Figure 16.6 is interpreted and used as follows:

Type - This indicates the type of C code used in the model. These types are described in Section 16.3 and 16.4.
S-Function Name - This gives the name of the S-Function used, where applicable. (As discussed in section 16.3 and 16.4, S-Function Libraries, Stateflow code, and Stateflow code libraries do not have associated S-Function names).
RSM File - This is the Reactis Make file (.rsm) that describes the necessary C files, includes, libraries, search paths and defines (as described in Section 16.3).
Location - This is the path location of the C code instance. If the type is Stateflow Custom C code, it can be accessed from any Stateflow chart in the model, so here it is labeled ’global’.

By right-clicking on a row of this dialog, you can bring up a menu to add, edit, or remove .rsm files. These functions are the same the ones presented when you right-click on an .rsm file in the model hierarchy panel.

Double-clicking on any line with a named S-Function will cause the Reactis main window to jump to that location in the model hierarchy, and briefly highlight that system. Double-clicking on a line whose location is ’global’ will only highlight the C code library in the hierarchy panel.

Clicking on each column heading will sort the rows alphabetically according to that column. In the example, some S-Function name and .rsm file columns have "n/a" (not applicable) in various locations. As explained in 16.4, code referenced from Stateflow does not have an associated S-Function, nor is an .rsm file required. Libraries that are referenced from Stateflow or S-Functions require an .rsm file, but do not have separate S-Functions.

16.6 C Code Coverage Criteria

Reactis uses a number of different coverage criteria to measure how thoroughly a test or set of tests exercises a model. In general, coverage criteria record how many of a given class of coverage targets (model features such as Stateflow states, C program statements, etc.) have been executed at least once. Coverage criteria may be visualized using Simulator and are central to test generation and model validation using Tester and Validator.

Chapter 6 describes the coverage criteria that are tracked within the Simulink and Stateflow portions of models. Those criteria include some which are specific to Simulink, some which appear only in Stateflow, and others which are generic and can appear in either Simulink or Stateflow. Three of the generic criteria are also tracked by the C code portions of models by Reactis for C Plugin. These are decision coverage, condition coverage, and modified condition / decision coverage (MC/DC).

Reactis for C Plugin uses precise criteria to determine which elements of C a program are decisions and which are conditions. A decision is any boolean-valued expression used to determine which execution path to follow. Conditions represent the atomic (i.e. smallest) boolean expressions within decisions. Specifically, decisions within a program are identified as follows:

For each if statement, the expression within parentheses following the if keyword is a decision.
For each while and do/while statement, the expression within parentheses following the while keyword is a decision.
For each for statement, the second expression within the parentheses following the for keyword is a decision.

Note that the argument expression of a switch statement is not a decision, and neither is the argument of the conditional expression operator pair ?:.

Decision coverage tracks whether each decision in a program has evaluated to both true and false.

Condition coverage tracks whether each condition in a program has evaluated to both true and false.

For the definition of MC/DC coverage, please see Chapter 6.

Finally, in addition to the generic coverage criteria discussed above, Reactis for C Plugin also tracks statement coverage, which records for each statement in a C program, whether or not the statement has been executed at least once.

16.6.1 Tracking Coverage in C Code

When Coverage -> Show Details in Simulator is selected, unexercised coverage targets in C code are reported visually as shown in Figure 16.7. Any unexecuted C statement is rendered in red. If a decision has not evaluated to true it has a thin red overline. If a decision has not evaluated to false it has a thin red underline. If a condition has not evaluated to true it has a thick red overline. If a condition has not evaluated to false it has a thick red underline. If a decision has not met the MC/DC criteria, then the text of the decision is displayed in red. The MC/DC-related coverage details associated with a decision (Figure 16.8) may be displayed by right clicking on the decision and selecting View Coverage Details. For a description of this dialog, please see Chapter 6.

Lines containing unexercised targets are distinguished by a a thin red bar which is drawn just to the right of the line number of that line.

Figure 16.7: Coverage highlighting in C code.

Figure 16.8: Viewing the MC/DC-related coverage details associated with a decision.

16.7 C Code in the Main Reactis Window

As shown in Figure 16.9, an .rsm file may be assigned, edited, or removed by right-clicking on the S-Function in the main panel when Simulator is disabled. After an .rsm file is assigned, the C source files for an S-Function are listed in the hierarchy panel and RSM appears in the upper right corner of the S-Function in the main panel.

Figure 16.9: Assigning .rsm files to S-Functions.

Figure 16.10 shows that a C file may be displayed in the main panel by clicking on the filename in the hierarchy panel. Line numbers and the grid may be turned on or off from the Reactis for C tab of the Settings dialog.

Figure 16.10: Clicking on a C filename in the hierarchy panel displays the C file in the main panel.

16.8 C Code and Reactis Simulator

When Reactis for C Plugin is enabled, Simulator seamlessly steps into Stateflow C code and S-Functions that have .rsm files assigned. The Simulator controls in the tool bar work in the same way within C code as they do for the Simulink and Stateflow portions of models. Five additional buttons are available to step through C source code. The behavior of those five and the Step Into button (also available when stepping through Simulink / Stateflow) is described below:

Reverse Step Out Of.: Step backwards to just before the currently executing function was called.
Reverse Step Over.: When paused after a function call, clicking this button steps back to just before the function was called.
Reverse Step Into.: Step backwards one statement. If a function call just returned step back to the last statement of the function.
Step Into.: Executes until either the current line of source code completes or a function is called.
Step Over.: Executes the current line of source code completes, including all function calls performed during its execution.
Step Out Of.: Executes until the current function completes.

Other buttons continue to operate the same as when not using the Reactis for C Plugin. For example, the step button ( ) reads all top-level inputs of the model and then executes the blocks (possibly including C code), updating the top-level outputs of the model with the results of the execution.

As shown in Figure 16.11, a breakpoint may be toggled on lines within a C file which contain an executable C statement by double-clicking just to the right of the line number, or by right-clicking to the right of the line number and selecting Toggle Breakpoint. When trying to set a breakpoint in C code on a line that does not contain an executable statement, Reactis remaps the breakpoint to a different line according to the following rules:

If the attempted breakpoint line is within a multi-line executable statement, the breakpoint is placed at the first line of multi-line statement.
It the attempted breakpoint line is on a line with no executable statement (e.g. a comment or a variable declaration) then the breakpoint is placed on the first subsequent line that contains an executable statement.

Note that the following are not executable statements:

type declarations,
function prototypes,
static variable declarations with or without an initializer,
declarations of uninitialized local variables,
preprocessor commands, and
lines which are empty or only contain comments.

When execution reaches a line containing a breakpoint, execution will he paused before the line is executed. While paused, hovering over many identifiers in the source code will cause information about the identifier to be displayed. The information displayed depends on the type of the identifier:

If the identifier is an instance of a macro, the expansion of the macro will be displayed.
If the identifier is a variable, information about the type and value of the variable will be displayed. In addition, pertinent source code locations, such as the location where the variable was last modified, will be displayed.
If the identifier is a function, the function type, the argument types and values, the location where the function is defined and the current call stack will be displayed.
If the identifier is a user-defined type, the type details will be displayed.
If the identifier is a pointer, the value pointed to is displayed.

For a description of how Simulator visually presents coverage information please see Section 16.6.1.

Figure 16.11: Debugging C code in Simulator.

The sizes and alignments of the common built-in C types under Reactis for C Plugin are listed in Table 16.1. These match the behavior of GCC (GNU C Compiler) and most other x86 C compilers. Integers are stored using a little endian byte order (the least-significant byte is stored first).

Type sizeof alignof

char, bool, void 1 1

short int 2 2

int, long int, float 4 4

long long int, double, long double^* 8 8

^* long double is not currently supported – it is mapped to type double.
Table 16.1: Sizes and alignments of the common C types, in bytes.

16.9 C Code and Reactis Tester

When Reactis for C Plugin is enabled, Tester automatically tries to exercise the coverage targets (described in Section 16.6) in Stateflow custom C code and S-Functions that have .rsm files assigned. The launch dialog includes a check-box to enable or disable C statement coverage.

16.10 C Code and Reactis Validator

Reactis Validator can check requirements on top-level S-Function inputs and outputs. To do so, Validator objectives are inserted within the subsystem which contains the S-Function. Reactis for C Plugin does not currently support the insertion of Validator objectives within the C code.

16.11 Integer Overflows

The C-plugin supports detection and flagging of overflows during operations on integer values. This feature can be turned on or off by changing the value of the On integer overflow configuration parameter, as discussed in Section 16.2.

When On integer overflow is set to Wrap Over, the C-plugin emulates the behavior of typical hardware, in which the most significant bits of a value which is too large are dropped until the value is small enough to be represented. The result of an unsigned wrapped-over overflow is typically equal to the large result modulo 2ⁿ, where n is the width (in bits) of the container type.

When signed values overflow, the sign bit may change, producing results much smaller or larger than if no overflow occurred. For example, in most 32-bit environments, adding the maximum signed int value (0x7fffffff) to itself produces the wrapped-over result −2.

When On integer overflow is set to Error, the C-plugin will stop execution and display an error dialog window whenever an integer computation overflows. When a signed integer addition, subtraction, multiplication or left shift operation is performed, the result is considered to have overflowed when it is too large or too small to be represented.

Note that according to the C language specification, no overflow occurs during unsigned computations. Instead, the result is computed by wrapping over the large value, using the modulo approach mentioned in the previous paragraph. This has the effect of truncating (in binary) the larger value. For example, assigning the value 0x1234u to an unsigned char variable is the same as assigning the value 0x34.

When a value of one integer type is converted to a value of a different integer type, an overflow can only occur when the destination type is signed. This means that the statements

int x = -1;
unsigned int y = x;

will not produce an overflow. Instead, y will receive the value 0xffffffff. However, if a third statement is added:

int x = -1;
unsigned int y = x;
x = y;

then an overflow will occur, because the value of y (0xffffffff) is larger than the maximum positive value that can be represented by x (0x7fffffff). To avoid such errors while catching arithmetic overflows, set On integer conversion overflow to Do nothing. Alternatively, the following macro can be used to convert an unsigned int to an int without causing an overflow:

#define UINT_TO_INT(x) \
 (((x) <= INT_MAX)? (int)(x) : \
                   (((int)((x)^INT_MIN))+INT_MIN))

The values INT_MAX and INT_MIN are defined in the system header file limits.h.

The C-plugin uses C99 rules for determining the signedness of expressions, which affects when overflows may occur. For integer constants, the type of the constant is determined by radix of the constant and the presence of a U or u suffix, as determined by the following rules:

Any integer constant with a U or u suffix is unsigned.
Any decimal constant without a U or u suffix is signed.
Any non-decimal constant X without a U or u suffix will be assigned the first type that can represent X from the following list: int, unsigned int, long long int, unsigned long long int. This means that 0xffffffff will be assigned type unsigned int and 4294967295 will be assigned type long long int even though the two values are equivalent. In the latter case, if the literal is changed to 4294967295U, it will be assigned type unsigned int.

The C99 rules for evaluating integer expressions state that values of any type smaller than int, including unsigned types, are first converted to type int before any subsequent evaluations are performed. This forces values of type unsigned short and unsigned char to become signed, so that, for example, adding two variables of type unsigned short will produce a signed int result.

When two integer values are combined in a binary expression, the width and signedness of the result are determined by two rules:

If one type is larger than the other, then the larger type is chosen.
If both types have the same size, then the result is unsigned if either type is unsigned.

Operator arguments are converted to the result type before the expression is evaluated. This means that the expression ((int)-1) > ((unsigned int)1) will evaluate to 0 (false).

16.12 Memory Errors

Whenever a pointer is used to access memory, Reactis for C Plugin performs a safety check to ensure that pointer is valid. There are two steps in the validity check:

Spatial validity. A pointer is not allowed to access memory outside of the bounds of the data object it originally pointed to (henceforth called the referent). For example, a pointer to an array can only be used to access memory within the bounds of the array. If A pointer is dereferenced and it points outside the bounds of its referent, then a spatial memory error occurs.
Temporal validity. The referent of a pointer must not have been deallocated prior to an access attempt. Pointers to heap objects are no longer temporally valid once the referent has been deallocated by a call to free(). Pointers to local variables of a function are no longer valid once the function has returned. Data stored in static memory, such as variables declared outside of a function scope are never deallocated and are hence always temporally valid. Attempts to access an temporally invalid referent result in a temporal memory error.

Note that it is possible that a program which appears to function correctly actually contains a memory error. For example, a function that sums an array may have an error in the iteration termination condition which causes the function to read 1 element past the end of the array. If the element which follows the end of the array happens to always be zero, this error may have never been detected. At some point the future, a change to the program may cause the invalid memory access to return a non-zero value. Even worse, there may be rare runtime conditions under which the memory access returns a non-zero value, causing intermittent program malfunctions which are difficult to reproduce and diagnose. Hence it is best to detect and fix such errors even though they may not seem to be presently causing a problem.

16.12.1 Invalid Pointer Creation

Reactis for C Plugin can produce an error or warning whenever a pointer expression produces an invalid pointer. This can help determine the source of a memory error. However, there are cases where invalid pointers are produced which are never dereferenced, such as the following program fragment:

int A[10], B[10], i, *a = A, *b = B;
while (i < 10) {
  *(a++) = *(b++);
}

During the last iteration of the above loop, the pointers a and b are both assigned invalid pointer values. This is not a problem because the invalid pointer values are never used. For such programs, the On invalid pointer creation setting should be set to Do nothing or Produce warning.

16.13 Other Runtime Errors

In addition to memory errors and overflows, the Reactis for C Plugin also detects the errors listed below. The C standard states that the results of these operations are undefined.

Divide by zero. An attempt to compute the quotient or remainder of a fraction in which the divisor is zero.
Invalid shift. An attempt to shift a value by an amount which is either (a) greater than or equal to the width of the value, or (b) a negative amount.

16.14 Unsupported C Features

Reactis for C Plugin supports a very large subset of the C99 standard. The following features, however, are not currently supported:

Variable-length arrays (e.g., int f(int n) { char s[n]; }).
ANSI Trigraphs.
Universal character codes (a \u or \U escape which can be followed by a UCS-2 or UCS-4 hex code).
Signals.
Types _Complex and _Imaginary.
Type long double.
Wide character types.
File I/O during simulation.
Designated initializers (e.g., struct { int x; int y; } s = { .y = 5 };).
Non-constant static initializers (e.g., static int A[1] = { f(x); };).

The following restrictions apply to white-box analysis of S-Functions:

All general restrictions for S-Function support as mentioned in Section 14.2.1.
MATLAB external interface functions dealing with sparse matrices (mxCreateSparse, mxCreateSparseLogicalMatrix, mxGetIr, mxGetJc, mxSetIr and mxSetJc) are not supported.
MATLAB external interface functions dealing with imaginary data (mxGetImagData,
mxGetPi, mxSetImagData, mxSetPi) are not supported.

In Stateflow custom C code, pointers to functions are not currently supported.

The following runtime library functions are currently unimplemented:

complex.h

cabsf cargf cimagf crealf cabs carg cimag creal cabsl cargl cimagl creall cacosf cacoshf casinf casinhf catanf catanhf ccosf ccoshf cexpf clogf conjf cpowf cprojf csinf csinhf csqrtf ctanf ctanhf cacos cacosh casin casinh catan catanh ccos ccosh cexp clog conj cpow cproj csin csinh csqrt ctan ctanh cacosl cacoshl casinl casinhl catanl catanhl ccosl ccoshl cexpl clogl conjl cpowl cprojl csinl csinhl csqrtl ctanl ctanhl

dlfcn.h

dlopen dlsym dlclose dlerror

fcntl.h

creat fcntl open close read write lseek unlink

math.h

asinh asinhf asinhl acosh acoshf acoshl atanh tanhf atanhl erf erff erfl erfc erfcf erfcl fam fmaf faml hypot hypotf hypotl lgamma lgammaf lgammal tgamma tgammaf tgammal expm1 expm1f exp1ml ilogb ilogbf ilogbl log1p log1pf log1pl rint rintf rintl

setjmp.h

sigsetjmp siglongjmp

signal.h

raise

stdio.h

freopen fseek ftell rewind fgetpos fsetpos ungetc fscanf scanf vfprintf vfscanf vscanf vsscanf fread fwrite feof ferror clearerr rename remove tmpfile tmpname

stdlib.h

atexit system execl execlp execle execv execvp execve bsearch qsort

unistd.h

access alarm brk chdir chroot chown close confstr crypt ctermid cuserid dup dup2 encrypt fchown fchdir fdatasync fork fpathconf fsync ftruncate getcwd getdtablesize getegid geteuid getgid getgroups gethostid getlogin getlogin_r getpagesize getpass getpgid getpgrp getpid getppid getsid getuid getwd isatty lchown link lockf lseek nice pathconf pause pipe pread pthread_atfork pwrite read readlink rmdir sbrk setgid setpgid setpgrp setregid setreuid setsid setuid sleep swab symlink sync sysconf tcgetpgrp tcsetpgrp truncate ttyname ttyname_r ualarm unlink usleep vfork write

utime.h

utime

wchar.h

wcscat wcsncat wcscmp wcsncmp wcscpy wcsncpy wcslen wcschr wcsrchr wcsspn wcscspn wcspbrk wcstok wcsstr wcscoll wcsxfrm wmemchr wmemcmp wmemcpy wmemmove wmemset fwide fgetwc getwc getwchar ungetwc fgetws fwscanf wscanf swscanf fputwc putwc putwchar fputws fwprintf wprintf swprintf vfwprintf vswprintf vwprintf vfwscanf vswscanf vwscanf

wctype.h

mbrlen btowc mbrtowc wctob wcrtomb mbsinit iswalnum iswalpha iswcntrl iswdigit iswxdigit iswgraph iswpunct iswprint iswlower iswupper iswspace towlower towupper wctype iswctype wctrans towctrans

16.15 Supported C library functions

The following C library functions are currently provided by Reactis for C Plugin.

assert.h

assert

ctype.h

isalnum isalpha isascii iscntrl iscsym iscsymf isdigit isxdigit isprint isgraph ispunct islower isupper isspace isblank toint tolower toupper

errno.h

strerror

fenv.h

fegetround fesetround

math.h

acos sqrt sin cos tan asin acos atan atan2 exp exp2 pow ln log log2 log10 sinh cosh tanh acosf sqrtf sinf cosf tanf asinf acosf atanf atan2f expf exp2f powf lnf logf log2f log10f sinhf coshf tanhf acosl sqrtl sinl cosl tanl asinl acosl atanl atan2l expl exp2l powl lnl logl log2l log10l sinhl coshl tanhl

memory.h

bcopy memccpy

setjmp.h

longjmp setjmp

stdarg.h

va_start va_arg va_copy va_end

stddef.h

offsetof

stdlib.h

malloc calloc realloc free abs labs llabs div ldiv lldiv atof atoi atol atoll strtof strtod strtold strtol strtoll strtoul strtoull exit _Exit abort getenv bsearch qsotr mblen mbtowc mbstowcs wcstombs rand srand

string.h

memchr memcmp memcpy memmove memset strlen strchr strcpy strncpy strcat strncat strcmp strncmp strspn strcspn strpbrk strtok strcoll strxfrm strdup strndup

tgmath.h

sin cos tan sinh cosh tanh asin acos atan exp exp2 sqrt cbrt ln log log2 erf erfc lgamma tgamma expm1 ilogb log1p fabs ceil floor nearbyint rint lrint round lround trunc atan2 pow copysign fdim hypot fmin fmax fmod remainder nextafter nexttoward frexp ldexp modf scalbn scalbnln remquo

1: The Target Options dialog is opened from the Stateflow window by selecting Tools -> Open Simulation Target... and then clicking the Target Options button.

Automated Testing and Validation with Reactis®

Chapter 16 Reactis for C Plugin

16.1 Quick Start

16.2 Configuring Reactis for C

16.3 S-Function C Code

16.3.1 Pathnames

16.3.2 S-Function Requirements

16.4 Stateflow Custom C Code

16.4.1 Stateflow Custom Code Requirements

16.5 C Code Tab in the Info File Editor

16.6 C Code Coverage Criteria

16.6.1 Tracking Coverage in C Code

16.7 C Code in the Main Reactis Window

16.8 C Code and Reactis Simulator

16.9 C Code and Reactis Tester

16.10 C Code and Reactis Validator

16.11 Integer Overflows

16.12 Memory Errors

16.12.1 Invalid Pointer Creation

16.13 Other Runtime Errors

16.14 Unsupported C Features

16.15 Supported C library functions