[intro.compliance] - C++23 → Trunk

Files changed (1) hide show

tmp/tmp1ua5tctf/{from.md → to.md} +89 -44

tmp/tmp1ua5tctf/{from.md → to.md} RENAMED Viewed

@@ -11,35 +11,43 @@ Although this document states only requirements on C++ implementations,
 those requirements are often easier to understand if they are phrased as
 requirements on programs, parts of programs, or execution of programs.
 Such requirements have the following meaning:
 - If a program contains no violations of the rules in [[lex]] through
-  [[thread]] and [[depr]], a conforming implementation shall, within its
- resource limits as described in [[implimits]], accept and correctly
- execute[^3] that program.
 - If a program contains a violation of a rule for which no diagnostic is
   required, this document places no requirement on implementations with
   respect to that program.
-- Otherwise, if a program contains a violation of any diagnosable rule
- or an occurrence of a construct described in this document as
     “conditionally-supported” when the implementation does not support
- that construct, a conforming implementation shall issue at least one
- diagnostic message.
 [*Note 1*: During template argument deduction and substitution, certain
 constructs that in other contexts require a diagnostic are treated
 differently; see  [[temp.deduct]]. — *end note*]
-Furthermore, a conforming implementation
-- shall not accept a preprocessing translation unit containing a
- `#error` preprocessing directive [[cpp.error]],
-- shall issue at least one diagnostic message for each `#warning` or
- `#error` preprocessing directive not following a `#error`
-  preprocessing directive in a preprocessing translation unit, and
-- shall not accept a translation unit with a *static_assert-declaration*
- that fails [[dcl.pre]].
 For classes and class templates, the library Clauses specify partial
 definitions. Private members [[class.access]] are not specified, but
 each implementation shall supply them to complete the definitions
 according to the description in the library Clauses.
@@ -56,82 +64,119 @@ header or importing the appropriate standard library named header unit
 The templates, classes, functions, and objects in the library have
 external linkage [[basic.link]]. The implementation provides definitions
 for standard library entities, as necessary, while combining translation
 units to form a complete C++ program [[lex.phases]].
-Two kinds of implementations are defined: a *hosted implementation* and
-a *freestanding implementation*. A freestanding implementation is one in
 which execution may take place without the benefit of an operating
 system. A hosted implementation supports all the facilities described in
 this document, while a freestanding implementation supports the entire
-C++ language described in [[lex]] through [[cpp]] and the subset of the
-library facilities described in [[compliance]].
 A conforming implementation may have extensions (including additional
 library functions), provided they do not alter the behavior of any
 well-formed program. Implementations are required to diagnose programs
 that use such extensions that are ill-formed according to this document.
 Having done so, however, they can compile and execute such programs.
 Each implementation shall include documentation that identifies all
 conditionally-supported constructs that it does not support and defines
-all locale-specific characteristics.[^4]
 ### Abstract machine <a id="intro.abstract">[[intro.abstract]]</a>
 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]
 Certain aspects and operations of the abstract machine are described in
-this document as implementation-defined (for example, `sizeof(int)`).
-These constitute the parameters of the abstract machine. 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).
 Certain other aspects and operations of the abstract machine are
-described in this document as unspecified (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.
 Certain other operations are described in this document as undefined
-(for example, the effect of attempting to modify a const object).
-[*Note 1*: This document imposes no requirements on the behavior of
-programs that contain undefined behavior. — *end note*]
 A conforming implementation executing a well-formed program shall
-produce the same observable behavior as one of the possible executions
-of the corresponding instance of the abstract machine with the same
-program and the same input. However, if any such execution contains an
-undefined operation, this document places no requirement on the
-implementation executing that program with that input (not even with
-regard to operations preceding the first undefined operation).
-The least requirements on a conforming implementation are:
 - Accesses through volatile glvalues are evaluated strictly according to
   the rules of the abstract machine.
-- At program termination, all data written into files shall be identical
- to one of the possible results that execution of the program according
- to the abstract semantics would have produced.
 - 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*.
-These collectively are referred to as the *observable behavior* of the
-program.
-[*Note 2*: More stringent correspondences between abstract and actual
 semantics can be defined by each implementation. — *end note*]

 those requirements are often easier to understand if they are phrased as
 requirements on programs, parts of programs, or execution of programs.
 Such requirements have the following meaning:
 - If a program contains no violations of the rules in [[lex]] through
+  [[exec]] as well as those specified in [[depr]], a conforming
+ implementation shall accept and correctly execute[^2] that program,
+ except when the implementation’s limitations (see below) are exceeded.
 - If a program contains a violation of a rule for which no diagnostic is
   required, this document places no requirement on implementations with
   respect to that program.
+- Otherwise, if a program contains
+ - a violation of any diagnosable rule,
+  - a preprocessing translation unit with a `#warning` preprocessing
+    directive [[cpp.error]],
+  - an occurrence of a construct described in this document as
     “conditionally-supported” when the implementation does not support
+ that construct, or
+ - a contract assertion [[basic.contract.eval]] evaluated with a
+    checking semantic in a manifestly constant-evaluated context
+    [[expr.const]] resulting in a contract violation,
+  a conforming implementation shall issue at least one diagnostic
+  message.
 [*Note 1*: During template argument deduction and substitution, certain
 constructs that in other contexts require a diagnostic are treated
 differently; see  [[temp.deduct]]. — *end note*]
+Furthermore, a conforming implementation shall not accept
+- a preprocessing translation unit containing a `#error` preprocessing
+  directive [[cpp.error]],
+- a translation unit with a *static_assert-declaration* that fails
+ [[dcl.pre]], or
+- a contract assertion evaluated with a terminating semantic
+  [[basic.contract.eval]] in a manifestly constant-evaluated context
+  [[expr.const]] resulting in a contract violation.
 For classes and class templates, the library Clauses specify partial
 definitions. Private members [[class.access]] are not specified, but
 each implementation shall supply them to complete the definitions
 according to the description in the library Clauses.
 The templates, classes, functions, and objects in the library have
 external linkage [[basic.link]]. The implementation provides definitions
 for standard library entities, as necessary, while combining translation
 units to form a complete C++ program [[lex.phases]].
+An implementation is either a *hosted implementation* or a
+*freestanding implementation*. A freestanding implementation is one in
 which execution may take place without the benefit of an operating
 system. A hosted implementation supports all the facilities described in
 this document, while a freestanding implementation supports the entire
+C++ language described in [[lex]] through [[\lastcorechapter]] and the
+subset of the library facilities described in [[compliance]].
+It is *implementation-defined* whether the implementation is a
+*hardened implementation*. If it is a hardened implementation, violating
+a hardened precondition results in a contract violation
+[[structure.specifications]].
+An implementation is encouraged to document its limitations in the size
+or complexity of the programs it can successfully process, if possible
+and where known. [[implimits]] lists some quantities that can be subject
+to limitations and a potential minimum supported value for each
+quantity.
+A conforming implementation may use an implementation-defined version of
+the Unicode Standard that is a later version than the one referenced in
+[[intro.refs]].
 A conforming implementation may have extensions (including additional
 library functions), provided they do not alter the behavior of any
 well-formed program. Implementations are required to diagnose programs
 that use such extensions that are ill-formed according to this document.
 Having done so, however, they can compile and execute such programs.
 Each implementation shall include documentation that identifies all
 conditionally-supported constructs that it does not support and defines
+all locale-specific characteristics.[^3]
 ### Abstract machine <a id="intro.abstract">[[intro.abstract]]</a>
 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.[^4]
 Certain aspects and operations of the abstract machine are described in
+this document as implementation-defined behavior (for example,
+`sizeof(int)`). These constitute the parameters of the abstract machine.
+Each implementation shall include documentation describing its
+characteristics and behavior in these respects.[^5]
 Such documentation shall define the instance of the abstract machine
 that corresponds to that implementation (referred to as the
 “corresponding instance” below).
 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.
 Certain other operations are described in this document as undefined
+behavior (for example, the effect of attempting to modify a const
+object).
+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*]
+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 contains an operation specified as
+having erroneous behavior, the implementation is permitted to issue a
+diagnostic and is permitted to terminate the execution at an unspecified
+time after that operation.
+*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*]
+The following specify the *observable behavior* of the program:
 - Accesses through volatile glvalues are evaluated strictly according to
   the rules of the abstract machine.
+- Data is delivered to the host environment to be written into files
+ (See also: ISO C 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*]
 - 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*]

Diff to HTML by rtfpessoa