Implementation-defined behavior

6.<x> FAB Implementation-defined behavior

6.<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.

[Look at BQF for a discussion of generalizing "recompiled"]

6.<x>.2 Cross reference

Ada: Clause 3.4.1 implementation-defined behavior [should be 1.1.3, annex m]

C: Clause 3.4.1 implementation-defined behavior [annex j.3]

C++: Clause 1.3.5 implementation-defined behavior

Fortran: ???

CWE: Nothing applicable

6.<x>.3 Categorization

See clause 5.1.2.

6.<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 [a range of ] behaviors. [delete - allowed by the language specification.]

[Instead, this should describe implementing a behavior that has been documented by the implementer and that might not be constrained by the standard.]

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.

6.<x>.5 Interrupting the failure mechanism

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.

6.<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.

6.<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.

[Consulting portability guides may be useful.]

History

Version 1, 30 June 2007, Author: Derek M. Jones, derek@knosof.co.uk