From Jason Turner

[intro.abstract]

C++23 → Trunk 5.6 KB 73 lines
Current Draft | LaTeX Source
Archived: C++23
Markdown: C++23 | Trunk
Explore in Adventure Game

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmpf4lcbf3n/{from.md → to.md} +46 -24
tmp/tmpf4lcbf3n/{from.md → to.md} RENAMED
@@ -3,57 +3,79 @@
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.[^5]
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.[^6]
15
 
16
  Such documentation shall define the instance of the abstract machine
17
  that corresponds to that implementation (referred to as the
18
  “corresponding instance” below).
19
 
20
  Certain other aspects and operations of the abstract machine are
21
- described in this document as unspecified (for example, order of
22
- evaluation of arguments in a function call [[expr.call]]). Where
23
  possible, this document defines a set of allowable behaviors. These
24
  define the nondeterministic aspects of the abstract machine. An instance
25
  of the abstract machine can thus have more than one possible execution
26
  for a given program and a given input.
27
 
28
  Certain other operations are described in this document as undefined
29
- (for example, the effect of attempting to modify a const object).
 
30
 
31
- [*Note 1*: This document imposes no requirements on the behavior of
32
- programs that contain undefined behavior. — *end note*]
 
 
 
 
 
 
 
 
 
 
 
33
 
34
  A conforming implementation executing a well-formed program shall
35
- produce the same observable behavior as one of the possible executions
36
- of the corresponding instance of the abstract machine with the same
37
- program and the same input. However, if any such execution contains an
38
- undefined operation, this document places no requirement on the
39
- implementation executing that program with that input (not even with
40
- regard to operations preceding the first undefined operation).
 
 
 
41
 
42
- The least requirements on a conforming implementation are:
 
 
 
 
 
 
 
 
43
 
44
  - Accesses through volatile glvalues are evaluated strictly according to
45
  the rules of the abstract machine.
46
- - At program termination, all data written into files shall be identical
47
- to one of the possible results that execution of the program according
48
- to the abstract semantics would have produced.
 
 
49
  - The input and output dynamics of interactive devices shall take place
50
  in such a fashion that prompting output is actually delivered before a
51
  program waits for input. What constitutes an interactive device is
52
  *implementation-defined*.
53
 
54
- These collectively are referred to as the *observable behavior* of the
55
- program.
56
-
57
- [*Note 2*: More stringent correspondences between abstract and actual
58
  semantics can be defined by each implementation. — *end note*]
59
 
 
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 behavior (for example,
12
+ `sizeof(int)`). These constitute the parameters of the abstract machine.
13
+ Each implementation shall include documentation describing its
14
+ characteristics and behavior in these respects.[^5]
15
 
16
  Such documentation shall define the instance of the abstract machine
17
  that corresponds to that implementation (referred to as the
18
  “corresponding instance” below).
19
 
20
  Certain other aspects and operations of the abstract machine are
21
+ described in this document as unspecified behavior (for example, order
22
+ of evaluation of arguments in a function call [[expr.call]]). Where
23
  possible, this document defines a set of allowable behaviors. These
24
  define the nondeterministic aspects of the abstract machine. An instance
25
  of the abstract machine can thus have more than one possible execution
26
  for a given program and a given input.
27
 
28
  Certain other operations are described in this document as undefined
29
+ behavior (for example, the effect of attempting to modify a const
30
+ object).
31
 
32
+ Certain events in the execution of a program are termed
33
+ *observable checkpoints*.
34
+
35
+ [*Note 1*: A call to `std::observable_checkpoint` [[utility.undefined]]
36
+ is an observable checkpoint, as are certain parts of the evaluation of
37
+ contract assertions [[basic.contract]]. — *end note*]
38
+
39
+ The *defined prefix* of an execution comprises the operations O for
40
+ which for every undefined operation U there is an observable checkpoint
41
+ C such that O happens before C and C happens before U.
42
+
43
+ [*Note 2*: The undefined behavior that arises from a data race
44
+ [[intro.races]] occurs on all participating threads. — *end note*]
45
 
46
  A conforming implementation executing a well-formed program shall
47
+ produce the observable behavior of the defined prefix of one of the
48
+ possible executions of the corresponding instance of the abstract
49
+ machine with the same program and the same input. If the selected
50
+ execution contains an undefined operation, the implementation executing
51
+ that program with that input may produce arbitrary additional observable
52
+ behavior afterwards. If the execution contains an operation specified as
53
+ having erroneous behavior, the implementation is permitted to issue a
54
+ diagnostic and is permitted to terminate the execution at an unspecified
55
+ time after that operation.
56
 
57
+ *Recommended practice:* An implementation should issue a diagnostic when
58
+ such an operation is executed.
59
+
60
+ [*Note 3*: An implementation can issue a diagnostic if it can determine
61
+ that erroneous behavior is reachable under an implementation-specific
62
+ set of assumptions about the program behavior, which can result in false
63
+ positives. — *end note*]
64
+
65
+ The following specify the *observable behavior* of the program:
66
 
67
  - Accesses through volatile glvalues are evaluated strictly according to
68
  the rules of the abstract machine.
69
+ - Data is delivered to the host environment to be written into files
70
+ (See also: ISO C 7.23.3). \[*Note 4*: Delivering such data is followed
71
+ by an observable checkpoint [[cstdio.syn]]. Not all host environments
72
+ provide access to file contents before program
73
+ termination. — *end note*]
74
  - The input and output dynamics of interactive devices shall take place
75
  in such a fashion that prompting output is actually delivered before a
76
  program waits for input. What constitutes an interactive device is
77
  *implementation-defined*.
78
 
79
+ [*Note 5*: More stringent correspondences between abstract and actual
 
 
 
80
  semantics can be defined by each implementation. — *end note*]
81