Implementation-defined behavior

8.<x> <unique immutable identifier> < Implementation-defined behavior>

8.<x>.1 Description of application vulnerability

A change of external behavior can occur when source code containing a construct having implementation-defined behavior is recompiled.

8.<x>.2 Cross reference

Ada: Clause 3.4.1 implementation-defined behavior

C: Clause 3.4.1 implementation-defined behavior

C++: Clause 1.3.5 implementation-defined behavior

Fortran: ???

CWE: Nothing applicable

8.<x>.3 Categorization

See clause 5.1.2.

8.<x>.4 Mechanism of failure

Language specifications do not always uniquely define the behavior of a construct. When they translate a instance of a construct that is not uniquely defined implementations are permitted to choose from the set of behaviors allowed by the language specification. The term 'implementation-defined behavior' is sometimes applied to such behaviors, and language specific guidelines need to analyse and document the terms used by their respective language.

It is possible that a developer uses a construct in a way that depends on a subset of the possible behaviors occurring. The behavior of a program containing such a usage is dependent on the translator used to compile it always selecting the 'expected' behavior.

8.<x>.5 Possible ways to avoid the vulnerability

Many language constructs may have implementation-defined behavior and recommending against use of these constructs may be completely impractical. For instance, in many languages the number of significant characters in an identifier implementation-defined. Other examples are along the lines of the example given for unspecified behavior [ref ???].

In the significant character example software developers may choose to only rely on the minimum number guaranteed or require that only translators supporting some number, N, of characters be used.

8.<x>.6 Assumed variations among languages

This vulnerability is intended to be applicable to languages with the following characteristics:

• All languages whose specification allows some variation in how a translator handles some construct, where this variation can result in differences in external behavior.

8.<x>.7 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• Ensuring that a specific use of a construct having implementation-defined behavior produces an external behavior that is the same, for that specific use, for all of possible behaviors permitted by the language specification.
• Only use a language implementation whose implementation-defined behaviors are within a known subset of implementation-defined behaviors. The known subset being chosen so that the 'same external behavior' condition described above is met.

History