Jones D.M.The new C standard (C90 and C++).An economic and cultural commentary.2005

C90

The title used in the C90 Standard was “Definitions and conventions”.

30 For the purposes of this International Standard, the following definitions apply.

C++

For the purposes of this International Standard, the definitions given in ISO/IEC 2382 and the following definitions apply.

The following subclauses describe the definitions (17.1), and method of description (17.3) for the library. Clause 17.4 and clauses 18 through 27 specify the contents of the library, and library requirements and constraints on both well-formed C++ programs and conforming implementations.

1.3p1

17p9

42

access

3.4.3

hexecution-time actioni to read or modify the value of an object

C++

In C++ the term access is used primarily in the sense of accessibility; that is, the semantic rules dealing with when identifiers declared in different classes and namespaces can be referred to. The C ++ Standard has a complete clause (Clause 11, Member access control) dealing with this issue. While the C++ Standard also uses access in the C sense (e.g., in 1.8p1), this is not the primary usage.

signed in- 681 teger con-

version implementation-

defined

The C99 wording has explicitly made the association between the terms implementation-defined and unspecified that was only implicit within the wording of the C90 Standard. It is possible to interpret the C90 definition as placing few restrictions on what an implementation-defined behavior might be. For instance, raising a signal or terminating program execution appear to be permitted. The C99 definition limits the possible behaviors to one of the possible behaviors permitted by the standard.

Behavior, upon use of a nonportable or erroneous program construct or of erroneous data, or of indeterminately valued objects, for which this International Standard imposes no requirements.

Use of an indeterminate value need not result in undefined behavior. If the value is read from an object that has unsigned char type, the behavior is unspecified. This is because objects of type unsigned char are required to represent values using a notation that does not support a trap representation.

3.4.4

49 unspecified behavior

use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance

C90

75 indeterminate

value

575 trap repre-

sentation reading is unde-

fined behavior

567 unsigned

char pure binary

unspecified behavior

This subclause describes restrictions on C++ programs that use the facilities of the C++ Standard Library.

This subclause describes the constraints upon, and latitude of, implementations of the C++ Standard library.

But they are not constraints in the C sense of requiring a diagnostic to be issued if they are violated. Like C, the C++ Standard does not require any diagnostics to be issued during program execution.

17.4.3 Constraints on programs

17.4.4p1

reference object

1.8p1

malloc function

effective type 941

While an object is also defined, 1.8p1, to be a region of storage in C ++, the term has many other connotations in an object-oriented language.

C++

The properties of an object are determined when the object is created.

This referenced/creation difference, compared to C, is possible in C++ because it contains the new and delete operators (as language keywords) for dynamic-storage allocation. The type of the object being created is known at the point of creation, which is not the case when the malloc library function is used (one of the reasons for the introduction of the concept of effective type in C99).

The C++ Standard does not provide an explicit definition for the term shall. However, since the C++ Standard was developed under ISO rules from the beginning, the default ISO rules should apply.

84If a “shall” or “shall not” requirement that appears outside of a constraint is violated, the behavior is undefined.

C++

ISO shall rules

shall outside constraint

This specification for the usage of shall does not appear in the C++ Standard. The ISO rules specify that the meaning of these terms does not depend on the kind of normative context in which they appear. One implication of this C specification is that the definition of the preprocessor is different in C ++. It was essentially copied verbatim from C90, which operated under different shall rules :-O.

ISO shall rules

85 Undefined behavior is otherwise indicated in this International Standard by the words “undefined behavior” or by the omission of any explicit definition of behavior.

C++

undefined behavior indicated by

88A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.3.

C90

This statement did not appear in the C90 Standard. It was added in C99 to make it clear that a strictly conforming program can contain constructs whose behavior is unspecified, provided the output is not affected by the behavior chosen by an implementation.

program

correct correct program

1.4p2

footnote 3

#error

terminate translation

C++

Although this International Standard 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 of this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute that program.

“Correct execution” can include undefined behavior, depending on the data being processed; see 1.3 and 1.9.

Programs which have the status, according to the C Standard, of being strictly conforming or conforming have no equivalent status in C++.

The implementation shall not successfully translate a preprocessing translation unit containing a #error 89 preprocessing directive unless it is part of a group skipped by conditional inclusion.

C90

C90 required that a diagnostic be issued when a #error preprocessing directive was encountered, but the translator was allowed to continue (in the sense that there was no explicit specification saying otherwise) translation of the rest of the source code and signal successful translation on completion.

16.5

strictly conforming program

use features of language/library

1.3.14 wellformed program

standard 1 specifies form

and interpretation

. . . , and renders the program ill-formed.

It is possible that a C++ translator will continue to translate a program after it has encountered a #error directive (the situation is as ambiguous as it was in C90).

A strictly conforming program shall use only those features of the language and library specified in this 90 International Standard.2)

C++

a C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule (3.2).

The C++ term well-formed is not as strong as the C term strictly conforming. This is partly as a result of the former language being defined in terms of requirements on an implementation, not in terms of requirements on a program, as in C’s case. There is also, perhaps, the thinking behind the C++ term of being able to check statically for a program being well-formed. The concept does not include any execution-time behavior (which strictly conforming does include). The C++ Standard does not define a term stronger than well-formed.

The C requirement to use only those library functions specified in the standard is not so clear-cut for freestanding C++ implementations.

For a hosted implementation, this International Standard defines the set of available libraries. A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries (17.4.1.3).

93 A conforming hosted implementation shall accept any strictly conforming program.

C++

conforming

hosted implementation

94 A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>.

C90

The header <iso646.h> was added in Amendment 1 to C90. Support for the complex types, the headers

conforming freestanding implementation

IEC 60559 29

footnote 3

conforming program

C90

The C90 Standard did not contain any conditional constructs.

C++

The C++ Standard also contains optional constructs. However, testing for the availability of any optional constructs involves checking the values of certain class members. For instance, an implementations support for the IEC 60559 Standard is indicated by the value of the member is_iec559 (18.2.1.2).

environment

translation environment

execution

An implementation translates C source files and executes C programs in two data-processing-system envi- 104 ronments, which will be called the translation environment and the execution environment in this International Standard.

C++

The C++ Standard says nothing about the environment in which C++ programs are translated.