|
288 | 288 |
|
289 | 289 | \indexdefn{behavior!undefined}%
|
290 | 290 | \definition{undefined behavior}{defns.undefined}
|
291 |
| -behavior for which this International Standard |
| 291 | +behavior for which this document |
292 | 292 | imposes no requirements
|
293 | 293 |
|
294 | 294 | \begin{defnote}
|
295 | 295 | Undefined behavior may be expected when
|
296 |
| -this International Standard omits any explicit |
| 296 | +this document omits any explicit |
297 | 297 | definition of behavior or when a program uses an erroneous construct or erroneous data.
|
298 | 298 | Permissible undefined behavior ranges
|
299 | 299 | from ignoring the situation completely with unpredictable results, to
|
|
314 | 314 | \begin{defnote}
|
315 | 315 | The implementation is not required to
|
316 | 316 | document which behavior occurs. The range of
|
317 |
| -possible behaviors is usually delineated by this International Standard. |
| 317 | +possible behaviors is usually delineated by this document. |
318 | 318 | \end{defnote}
|
319 | 319 |
|
320 | 320 | \indexdefn{program!well-formed}%
|
|
354 | 354 | \indextext{conformance requirements!general|(}%
|
355 | 355 | The set of
|
356 | 356 | \defn{diagnosable rules}
|
357 |
| -consists of all syntactic and semantic rules in this International |
358 |
| -Standard except for those rules containing an explicit notation that |
| 357 | +consists of all syntactic and semantic rules in this document |
| 358 | +except for those rules containing an explicit notation that |
359 | 359 | ``no diagnostic is required'' or which are described as resulting in
|
360 | 360 | ``undefined behavior''.
|
361 | 361 |
|
362 | 362 | \pnum
|
363 | 363 | \indextext{conformance requirements!method of description}%
|
364 |
| -Although this International Standard states only requirements on \Cpp |
| 364 | +Although this document states only requirements on \Cpp |
365 | 365 | implementations, those requirements are often easier to understand if
|
366 | 366 | they are phrased as requirements on programs, parts of programs, or
|
367 | 367 | execution of programs. Such requirements have the following meaning:
|
368 | 368 | \begin{itemize}
|
369 | 369 | \item
|
370 | 370 | If a program contains no violations of the rules in this
|
371 |
| -International Standard, a conforming implementation shall, |
| 371 | +document, a conforming implementation shall, |
372 | 372 | within its resource limits, accept and correctly execute\footnote{``Correct execution'' can include undefined behavior, depending on
|
373 | 373 | the data being processed; see \ref{intro.defs} and~\ref{intro.execution}.}
|
374 | 374 | that program.
|
375 | 375 | \item
|
376 | 376 | \indextext{message!diagnostic}%
|
377 | 377 | If a program contains a violation of any diagnosable rule or an occurrence
|
378 |
| -of a construct described in this International Standard as ``conditionally-supported'' when |
| 378 | +of a construct described in this document as ``conditionally-supported'' when |
379 | 379 | the implementation does not support that construct, a conforming implementation
|
380 | 380 | shall issue at least one diagnostic message.
|
381 | 381 | \item
|
382 | 382 | \indextext{behavior!undefined}%
|
383 | 383 | If a program contains a violation of a rule for which no diagnostic
|
384 |
| -is required, this International Standard places no requirement on |
| 384 | +is required, this document places no requirement on |
385 | 385 | implementations with respect to that program.
|
386 | 386 | \end{itemize}
|
387 | 387 | \begin{note}
|
|
421 | 421 | \pnum
|
422 | 422 | Two kinds of implementations are defined: a \defn{hosted implementation} and a
|
423 | 423 | \defn{freestanding implementation}. For a hosted implementation, this
|
424 |
| -International Standard defines the set of available libraries. A freestanding |
| 424 | +document defines the set of available libraries. A freestanding |
425 | 425 | implementation is one in which execution may take place without the benefit of
|
426 | 426 | an operating system, and has an \impldef{required libraries for freestanding
|
427 | 427 | implementation} set of libraries that includes certain language-support
|
|
432 | 432 | additional library functions), provided they do not alter the
|
433 | 433 | behavior of any well-formed program.
|
434 | 434 | Implementations are required to diagnose programs that use such
|
435 |
| -extensions that are ill-formed according to this International Standard. |
| 435 | +extensions that are ill-formed according to this document. |
436 | 436 | Having done so, however, they can compile and execute such programs.
|
437 | 437 |
|
438 | 438 | \pnum
|
|
777 | 777 | \pnum
|
778 | 778 | \indextext{program execution|(}%
|
779 | 779 | \indextext{program execution!abstract machine}%
|
780 |
| -The semantic descriptions in this International Standard define a |
781 |
| -parameterized nondeterministic abstract machine. This International |
782 |
| -Standard places no requirement on the structure of conforming |
| 780 | +The semantic descriptions in this document define a |
| 781 | +parameterized nondeterministic abstract machine. This document |
| 782 | +places no requirement on the structure of conforming |
783 | 783 | implementations. In particular, they need not copy or emulate the
|
784 | 784 | structure of the abstract machine.
|
785 | 785 | \indextext{as-if rule}%
|
786 | 786 | \indextext{behavior!observable}%
|
787 | 787 | Rather, conforming implementations are required to emulate (only) the observable
|
788 | 788 | behavior of the abstract machine as explained below.\footnote{This provision is
|
789 | 789 | sometimes called the ``as-if'' rule, because an implementation is free to
|
790 |
| -disregard any requirement of this International Standard as long as the result |
| 790 | +disregard any requirement of this document as long as the result |
791 | 791 | is \emph{as if} the requirement had been obeyed, as far as can be determined
|
792 | 792 | from the observable behavior of the program. For instance, an actual
|
793 | 793 | implementation need not evaluate part of an expression if it can deduce that its
|
|
799 | 799 | \indextext{behavior!implementation-defined}%
|
800 | 800 | \pnum
|
801 | 801 | Certain aspects and operations of the abstract machine are described in this
|
802 |
| -International Standard as implementation-defined (for example, |
| 802 | +document as implementation-defined (for example, |
803 | 803 | \tcode{sizeof(int)}). These constitute the parameters of the abstract machine.
|
804 | 804 | Each implementation shall include documentation describing its characteristics
|
805 | 805 | and behavior in these respects.\footnote{This documentation also includes
|
|
811 | 811 | \indextext{behavior!unspecified}%
|
812 | 812 | \pnum
|
813 | 813 | Certain other aspects and operations of the abstract machine are
|
814 |
| -described in this International Standard as unspecified (for example, |
| 814 | +described in this document as unspecified (for example, |
815 | 815 | evaluation of expressions in a \grammarterm{new-initializer} if the allocation
|
816 | 816 | function fails to allocate memory\iref{expr.new}). Where possible, this
|
817 |
| -International Standard defines a set of allowable behaviors. These |
| 817 | +document defines a set of allowable behaviors. These |
818 | 818 | define the nondeterministic aspects of the abstract machine. An instance
|
819 | 819 | of the abstract machine can thus have more than one possible execution
|
820 | 820 | for a given program and a given input.
|
821 | 821 |
|
822 | 822 | \indextext{behavior!undefined}%
|
823 | 823 | \pnum
|
824 |
| -Certain other operations are described in this International Standard as |
| 824 | +Certain other operations are described in this document as |
825 | 825 | undefined (for example, the effect of
|
826 | 826 | attempting to modify a \tcode{const} object).
|
827 |
| -\begin{note} This International Standard imposes no requirements on the |
| 827 | +\begin{note} This document imposes no requirements on the |
828 | 828 | behavior of programs that contain undefined behavior. \end{note}
|
829 | 829 |
|
830 | 830 | \indextext{program!well-formed}%
|
|
835 | 835 | of the corresponding instance of the abstract machine with the
|
836 | 836 | same program and the same input.
|
837 | 837 | \indextext{behavior!undefined}%
|
838 |
| -However, if any such execution contains an undefined operation, this International Standard places no |
| 838 | +However, if any such execution contains an undefined operation, this document places no |
839 | 839 | requirement on the implementation executing that program with that input
|
840 | 840 | (not even with regard to operations preceding the first undefined
|
841 | 841 | operation).
|
|
1181 | 1181 | through a pointer or reference\iref{basic.compound}.} Under a hosted
|
1182 | 1182 | implementation, a \Cpp program can have more than one thread running
|
1183 | 1183 | concurrently. The execution of each thread proceeds as defined by the remainder
|
1184 |
| -of this International Standard. The execution of the entire program consists of an execution |
| 1184 | +of this document. The execution of the entire program consists of an execution |
1185 | 1185 | of all of its threads. \begin{note} Usually the execution can be viewed as an
|
1186 | 1186 | interleaving of all its threads. However, some kinds of atomic operations, for
|
1187 | 1187 | example, allow executions inconsistent with a simple interleaving, as described
|
|
1511 | 1511 | \pnum
|
1512 | 1512 | \begin{note} Compiler transformations that introduce assignments to a potentially
|
1513 | 1513 | shared memory location that would not be modified by the abstract machine are
|
1514 |
| -generally precluded by this International Standard, since such an assignment might overwrite |
| 1514 | +generally precluded by this document, since such an assignment might overwrite |
1515 | 1515 | another assignment by a different thread in cases in which an abstract machine
|
1516 | 1516 | execution would not have encountered a data race. This includes implementations
|
1517 | 1517 | of data member assignment that overwrite adjacent members in separate memory
|
|
1522 | 1522 | \pnum
|
1523 | 1523 | \begin{note} Transformations that introduce a speculative read of a potentially
|
1524 | 1524 | shared memory location may not preserve the semantics of the \Cpp program as
|
1525 |
| -defined in this International Standard, since they potentially introduce a data race. However, |
| 1525 | +defined in this document, since they potentially introduce a data race. However, |
1526 | 1526 | they are typically valid in the context of an optimizing compiler that targets a
|
1527 | 1527 | specific machine with well-defined semantics for data races. They would be
|
1528 | 1528 | invalid for a hypothetical machine that is not tolerant of races or provides
|
|
0 commit comments