tmp/tmpxy28bgx6/{from.md → to.md}
RENAMED
|
@@ -0,0 +1,57 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
### Abstract machine <a id="intro.abstract">[[intro.abstract]]</a>
|
| 2 |
+
|
| 3 |
+
The semantic descriptions in this document define a parameterized
|
| 4 |
+
nondeterministic abstract machine. This document places no requirement
|
| 5 |
+
on the structure of conforming implementations. In particular, they need
|
| 6 |
+
not copy or emulate the structure of the abstract machine. Rather,
|
| 7 |
+
conforming implementations are required to emulate (only) the observable
|
| 8 |
+
behavior of the abstract machine as explained below.[^4]
|
| 9 |
+
|
| 10 |
+
Certain aspects and operations of the abstract machine are described in
|
| 11 |
+
this document as implementation-defined (for example, `sizeof(int)`).
|
| 12 |
+
These constitute the parameters of the abstract machine. Each
|
| 13 |
+
implementation shall include documentation describing its
|
| 14 |
+
characteristics and behavior in these respects.[^5] Such documentation
|
| 15 |
+
shall define the instance of the abstract machine that corresponds to
|
| 16 |
+
that implementation (referred to as the “corresponding instance” below).
|
| 17 |
+
|
| 18 |
+
Certain other aspects and operations of the abstract machine are
|
| 19 |
+
described in this document as unspecified (for example, order of
|
| 20 |
+
evaluation of arguments in a function call [[expr.call]]). Where
|
| 21 |
+
possible, this document defines a set of allowable behaviors. These
|
| 22 |
+
define the nondeterministic aspects of the abstract machine. An instance
|
| 23 |
+
of the abstract machine can thus have more than one possible execution
|
| 24 |
+
for a given program and a given input.
|
| 25 |
+
|
| 26 |
+
Certain other operations are described in this document as undefined
|
| 27 |
+
(for example, the effect of attempting to modify a const object).
|
| 28 |
+
|
| 29 |
+
[*Note 1*: This document imposes no requirements on the behavior of
|
| 30 |
+
programs that contain undefined behavior. — *end note*]
|
| 31 |
+
|
| 32 |
+
A conforming implementation executing a well-formed program shall
|
| 33 |
+
produce the same observable behavior as one of the possible executions
|
| 34 |
+
of the corresponding instance of the abstract machine with the same
|
| 35 |
+
program and the same input. However, if any such execution contains an
|
| 36 |
+
undefined operation, this document places no requirement on the
|
| 37 |
+
implementation executing that program with that input (not even with
|
| 38 |
+
regard to operations preceding the first undefined operation).
|
| 39 |
+
|
| 40 |
+
The least requirements on a conforming implementation are:
|
| 41 |
+
|
| 42 |
+
- Accesses through volatile glvalues are evaluated strictly according to
|
| 43 |
+
the rules of the abstract machine.
|
| 44 |
+
- At program termination, all data written into files shall be identical
|
| 45 |
+
to one of the possible results that execution of the program according
|
| 46 |
+
to the abstract semantics would have produced.
|
| 47 |
+
- The input and output dynamics of interactive devices shall take place
|
| 48 |
+
in such a fashion that prompting output is actually delivered before a
|
| 49 |
+
program waits for input. What constitutes an interactive device is
|
| 50 |
+
*implementation-defined*.
|
| 51 |
+
|
| 52 |
+
These collectively are referred to as the *observable behavior* of the
|
| 53 |
+
program.
|
| 54 |
+
|
| 55 |
+
[*Note 2*: More stringent correspondences between abstract and actual
|
| 56 |
+
semantics may be defined by each implementation. — *end note*]
|
| 57 |
+
|