Studio:SCL Design Requirements

The STRIDE Communication Language (SCL) is a description language used to unambiguously define messages, Remote Function Calls (RFCs), and trace points. The SCL uses standard C syntax along with a set of pragmas to fully describe both types of interfaces and trace points. Refer to the SCL Data Types page for more information about compliant data types.

Because an interface definition is independent of the implementation, the SCL requires all interfaces and trace points to be defined within a standard C header file. The following is a set of design constraints required to enable the SCL to be independent of any specific development environment.

Pragma usage

Interfaces and trace points are identified using special SCL pragmas contained in header file(s). SCL pragmas are also used to further describe unique parameters and/or fields defined as part of the interface. For example, pointers are ambiguous concerning direction and require further qualification, such as declaring the pointer as input, output, or both. Pragmas can be defined in a separate header that includes other header files containing the prototypes, data structures, etc., or they can be directly inserted into the application header file(s).

The SCL Wizard section of the STRIDE Online Help shows you how to streamline and simplify working with pragmas by allowing you to quickly capture interfaces and accurately qualify payloads and types.

Interfaces defined in header files

Interface definitions (e.g., prototypes, message data structures) must be contained in a standard C header file. All associated user-defined data types (e.g., enumerators, structures, etc.) are also required to be in a header file.

Trace points defined within a header file

Trace point definitions (e.g., data structures, unique IDs, etc.) must be contained in a standard C header file.

Globally scoped routines

Functions identified for remote usages must be declared global in scope (they cannot be static). Intercept Modules work with any compiler and require name binding during compilation.

Nested include protection

All header files that contain SCL pragmas, data structures, etc., are required to protect against nested inclusion. The following is a recommended approach to protect against including a file more than once:

Syntax

#ifndef <FILE_NAME_H>
#define <FILE_NAME_H>

  //... body of header file
 
#endif /* <FILE_NAME_H> */

Protecting against unique compiler directives

All header files that contain SCL pragmas, data structures, prototypes, etc., are required to protect against using non-standard compiler directives. A recommended approach is to define the directive as empty when using an SCL front-end compiler:

Syntax

#ifdef _SCL
#define _inline
  //...
#endif

Avoiding interception name mangling conflicts

To avoid name mangling conflicts when using interceptors (formal delegates), it is recommended that the implementation of routines (Definition) and the callers of the routines (Reference) be placed in separate C source files.

See Also

• SCL Pragmas
• SCL Structure
• SCL Data Types
• SCL Message Attributes
• For detailed instructions on working with SCL, including code samples and examples, refer to the SCL Reference Guide.
• Refer to the SCL Wizard section of the STRIDE Online Help for information on how to create SCL pragmas.