Certification Authorities Software Team (CAST)

Position Paper

CAST-8

####### Use of the C++ Programming Language

Completed January, 2002

####### Use of the C++ Programming Language

# 

# **1. BACKGROUND**

> The C++ language has several features that, if not controlled
> properly, can lead to unknown configurations of object code and
> unverified code. These issues can be divided into two categories: (1)
> compile-time issues and (2) run-time issues. There may be some overlap
> between these categories.
>
> Issues addressed in this paper may also be applicable to other
> languages. Additionally, other languages may have other issues not
> addressed in this paper. The issues documented in this paper may not
> be all-inclusive (i.e., there may be other C++ issues that need to be
> addressed).

# **2. COMPILE-TIME ISSUES** 

> The compile-time issues that should be addressed by the applicant are:

***2.1 [Dead/Deactivated Code]{.underline}:*** Several variations of
this can occur in object-oriented systems. A few are: (a) classes in a
library not used; (b) methods (functions) of a class not called in a
particular application; (c) methods (functions) of a class overridden in
all subclasses; or (d) attributes of a class not accessed in a
particular application. This can result in substantial dead code and
deactivated code, and can substantially complicate traceability
(especially for Level A software) and verification (especially for
unintended function and structural coverage analysis).

***2.2 [Encapsulation]{.underline}:*** Separation of the external
(public) and internal (private) aspects of a class and its objects.
Generally, the external aspects are known as the interface, while the
internal aspects are known as the implementation. Clients of a class may
only have access to the interface of the objects of that class and not
to the internal aspects (also known as data hiding, information hiding).
The concerns of encapsulation in airborne systems are:

a)  The programmer may not be aware of unintended functionality of the
    class, if class features, potential side effects, pre-conditions,
    and post-conditions are not well-documented;

b)  Traceability and configuration control of classes may become
    difficult to manage; and

c)  Structural coverage may be difficult to accomplish.

***2.3 [Inheritance]{.underline}:*** A mechanism whereby a class is
defined in terms of others (its parents), adding the features of its
parents to its own. A class may have a single parent (single
inheritance) or multiple parents (multiple inheritance). Either the
interface, or the interface and implementation can be inherited. Where
multiple inheritance is allowed, repeated inheritance is a possibility
(two or more parents have a common ancestor in the class hierarchy).
Multiple inheritance is particularly a concern in airborne systems. It
can lead to overly complex and potentially unpredictable interactions
between classes. It can also complicate traceability and verification.

***2.4 [Overloading]{.underline}:*** Overloading is a feature where
operators, multiple functions (or methods) have the identical name or
symbol but are differentiated (e.g., different number and type of
arguments). The matching of calls to the correct methods at compile time
may be difficult to determine.

# 

# **3. RUN-TIME ISSUES**

> The run-time issues that should be addressed by the applicant are:

***3.1 [Dynamic Binding/Dispatch:]{.underline}*** The matching of calls
to methods (functions) at run-time as opposed to compile-time or
link-time. This results from a polymorphic call. There are a number of
concerns regarding the use of dynamic binding/dispatch in airborne
software:

a)  It complicates the flow analysis (e.g., data coupling and control
    coupling) and structural coverage analysis;

b)  It can lead to complex and error-prone code;

c)  It can complicate source code to object code traceability;

d)  The matching of calls to methods can be difficult, if implicit type
    conversion is used; and

e)  The behavior of the execution of the compiler-generated code may not
    meet what the programmer expected.

***3.2 [Polymorphism:]{.underline}*** The ability of a name in software
text to denote, at run-time, one or more possible entities, such as a
function, a variable or an operator. For example, given the text:
*f(x)*, which *f()* to call may be dependent on which class *x* belongs
to, and *x* may belong to multiple classes, depending on the run-time
state of the system. Polymorphism is generally supported by dynamic
binding/dispatch. The concern with polymorphism in airborne systems is
the potential for ambiguity, which might lead to coding errors,
traceability complexity, and verification difficulty.

# **4. CAST POSITION**

> Many C++ features, if not properly controlled and verified, can result
> in software code that is non-deterministic, unused, or difficult to
> verify, and whose configuration can change depending on the run-time
> state of the system.
>
> Applicants who use C++ in their airborne systems should address:

-   each of the above issues,

-   any other issues related to the use of the C++ programming language
    identified during the specific certification project, and

-   any issues related to the use of compiler-provided library
    functions.

> The applicant should provide substantiating software plans, standards,
> and verification data to show that each of these issues, as well as
> any other identified issues, will be controlled and to ensure that an
> appropriate level of assurance is achieved for each.