4 General principles [intro]

4.1 Implementation compliance [intro.compliance]

4.1.2 Abstract machine [intro.abstract]

1
#
The semantic descriptions in this document define a parameterized nondeterministic abstract machine.
This document places no requirement on the structure of conforming implementations.
In particular, they need not copy or emulate the structure of the abstract machine.
Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.5
2
#
Certain aspects and operations of the abstract machine constitute the parameters of the abstract machine and are described in this document as implementation-defined behavior (for example, sizeof(int)) or as properties of the implementation (for example, padding in class types).
For implementation-defined behavior, each implementation shall include documentation describing its characteristics and behavior in these respects.6
Such documentation shall define the instance of the abstract machine that corresponds to that implementation (referred to as the “corresponding instance” below).
3
#
Certain other aspects and operations of the abstract machine are described in this document as unspecified behavior (for example, order of evaluation of arguments in a function call ([expr.call])).
Where possible, this document defines a set of allowable behaviors.
These define the nondeterministic aspects of the abstract machine.
An instance of the abstract machine can thus have more than one possible execution for a given program and a given input.
4
#
Certain other operations are described in this document as undefined behavior (for example, the effect of attempting to modify a const object).
5
#
Certain events in the execution of a program are termed observable checkpoints.
[Note 1: 
A call to std​::​observable_checkpoint ([utility.undefined]) is an observable checkpoint, as are certain parts of the evaluation of contract assertions ([basic.contract]).
— end note]
6
#
The defined prefix of an execution comprises the operations O for which for every undefined operation U there is an observable checkpoint C such that O happens before C and C happens before U.
[Note 2: 
The undefined behavior that arises from a data race ([intro.races]) occurs on all participating threads.
— end note]
A conforming implementation executing a well-formed program shall produce the observable behavior of the defined prefix of one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input.
If the selected execution contains an undefined operation, the implementation executing that program with that input may produce arbitrary additional observable behavior afterwards.
If the execution of an operation is specified as having erroneous behavior, the implementation is permitted to issue a diagnostic and is permitted to terminate the execution of the program.
7
#
Recommended practice: An implementation should issue a diagnostic when such an operation is executed.
[Note 3: 
An implementation can issue a diagnostic if it can determine that erroneous behavior is reachable under an implementation-specific set of assumptions about the program behavior, which can result in false positives.
— end note]
8
#
The following specify the observable behavior of the program:
  • (8.1)
    Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.
  • (8.2)
    Data is delivered to the host environment to be written into files (See also: ISO/IEC 9899:2024, 7.23.3).
    [Note 4: 
    Delivering such data is followed by an observable checkpoint ([cstdio.syn]).
    Not all host environments provide access to file contents before program termination.
    — end note]
  • (8.3)
    The input and output dynamics of interactive devices shall take place in such a fashion that prompting output is actually delivered before a program waits for input.
    What constitutes an interactive device is implementation-defined.
[Note 5: 
More stringent correspondences between abstract and actual semantics can be defined by each implementation.
— end note]
5)5)
This provision is sometimes called the “as-if” rule, because an implementation is free to disregard any requirement of this document as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior of the program.
For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced.
6)6)
This documentation also includes conditionally-supported constructs and locale-specific behavior.