parts/4.6.UndefinedBehaviour.md

4.6 Unspecified, Undefined and Implementation-defined behaviour

4.6.1 Undefined Behavior.md

The C++ standard defines undefined behaviour as behavior for which the C++ standard document imposes no requirements. The previous statement means that a program that uses a mechanism that invokes undefined behaviour can see any result ranging from the expected result up to and including a loss of the entire system. Even when a program behaviour based on a situation that includes undefined behaviour is acceptable during testing, its behaviour can change on the next execution with potentially disasterous results. Compilers are not required to identify constructs with undefined behaviour, yet avoidance of such constructs is essential.

Subclause 6.56 documents associated vulnerabilities for undefined behaviour.

4.6.2 Unspecified Behaviour

According to the C++ standard, unspecfied behaviour is behaviour, for a well-formed program construct with correct data, that depends on the implementation. The implementation is not required to document the behaviour and the result could be unexpected. For example, the order of evaluation of function parameters is unspecified, but irrelevant if there is no dependency between the actual parameters of a call. Another class of unspecified behaviour are ones that by themselves seem innocuous but subsequent use of unspecified results can lead to undefined behaviour.

The following shows (move to 6.55)

char data[1 + int(1 + 0.2 - 0.1 - 0.1)] = { };
int size = 1 + int(1 + 0.2 - 0.1 - 0.1);
char f() { return data[size-1];} // Possible buffer overflow

This example permits the value of size to be different than the length of data because the size definition is executed at runtime and the definition of data must be completed at compile time, which is one source of unspecified behaviour. Subclause 6.55 documents associated vulnerabilities for unspecified behaviour.

4.6.3 Implemation-defined behaviour

According to the C++ standard, implementation-defined behaviour is behaviour, for a well-formed program construct with correct data, that depends on the implementation and each implementation is required to document. Any change in toolchain, version of the implementation, or switches used in program construction can result in changes to runtime behaviour.

Subclause 6.57 documents associated vulnerabilities for implementation-defined behaviour.