C, Ocean Edition I

3. Terms and Definitions

Clause
3
ISO C99 mapping
3
Status
Normative

3.0 Using This Clause

For the purposes of this specification, the following terms apply. Terms not defined here and not defined at their point of use carry their ordinary meaning in ISO/IEC 2382 or in ordinary programming usage.

Definitions are ordered alphabetically. A definition that differs from the corresponding ISO C99 definition carries a Difference note.


3.1 access

To read the value of an object, or to modify the value of an object.

A read is an access. A write is an access. A read-modify-write operation performs both, in that order.

An access to a volatile-qualified object is externally observable and shall actually occur. See clause 6.7.3.4.


3.2 aggregate type

A structure type or an array type.

A union type is not an aggregate type. It is a distinct category, because its members overlap rather than being laid out beside one another.


3.3 alignment

A requirement that an object of a given type be placed at an address that is a multiple of a target-determined value.

Every complete object type has an alignment requirement of at least one byte. The alignment of a type is determined by the selected target ABI.


3.4 argument

An expression in the comma-separated list bounded by the parentheses of a function call.


3.5 array

A complete object type consisting of a contiguous, nonempty, fixed-length sequence of objects of one element type.

An array is a first-class object in Ocean Edition I. An expression of array type has array type in every context. See clause 6.3.2.1 and behavior.md section 24.


3.6 artifact

Any file an implementation produces from a translation or a link, including object files, archives, shared libraries, executable images, debug information, and auxiliary output.

Every artifact is subject to the reproducibility requirement of clause 4.10. See annex-k-deterministic-translation.md.


3.7 behavior

The external appearance or action of a program or of a construct.

Difference: ISO C99 divides behavior into defined, unspecified, undefined, implementation-defined, and locale-specific. Ocean Edition I uses defined behavior, implementation-defined behavior, defined trap, and unsafe memory behavior. See clause 0.3.


3.8 bit

The smallest unit of data storage, large enough to hold an object that can have one of two values.


3.9 byte

An addressable unit of data storage, exactly eight bits wide, large enough to hold any member of the basic character set of the execution environment.

The char type occupies exactly one byte. sizeof(char) is 1.

Difference: ISO C99 requires a byte to be at least eight bits and permits wider bytes. Ocean Edition I fixes the width at eight, because every supported target agrees and the freedom purchased nothing. See clause 6.2.6.1 and behavior.md section 112.


3.10 canonical spelling

The one spelling of a construct that Ocean Edition I retains where ISO C99 accepts several spellings with identical meaning.

A noncanonical spelling of a retained construct is a constraint violation. See clause 6.7.2 and syntax.md sections 18 and 19.


3.11 character

A member of the source or execution character set.

A single-byte character is a bit representation that fits in a byte.


3.12 complete type

A type with enough information to determine the size of an object of that type.

An incomplete type omits that information. void is an incomplete type that cannot be completed.


3.13 constraint

A syntactic or semantic restriction on programs.

An implementation shall produce a diagnostic message for every constraint violation it encounters, and shall not translate the program. See clause 4.3.


3.14 correctly rounded result

A representation in the result format that is nearest in value, subject to the current rounding mode, to what the result would be given unlimited range and precision.


3.15 declared translation timestamp

The timestamp that a build declares for itself, forming part of the build configuration and supplying the value of __DATE__ and __TIME__.

It is determined by Annex K clause K.5.1 and is never a reading of the wall clock.


3.16 defined trap

A behavior category. The operation cannot produce a valid result, and execution stops through the implementation's documented trap mechanism.

A trap is not undefined behavior. The point at which execution stops is determined, and operations sequenced before it have completed. See clause 0.3, clause 4.7, and annex-d-defined-traps-and-unsafe-operations.md.


3.17 diagnostic message

A message belonging to a subset of the implementation's output messages that the implementation identifies as diagnostic.

An implementation shall document how a diagnostic message is distinguished from other output.


3.18 element pointer

A pointer to an element of an array, most often written &a[0].

Ocean Edition I uses this term where ISO C99 would say that an array "decayed". Nothing decays. An element pointer is produced by an operator the programmer wrote. See syntax.md section 23.


3.19 enclosing namespace

The namespace whose definition or directive lexically contains a declaration, or the global namespace where no namespace contains it.

Where namespaces nest, a declaration has several enclosing namespaces, and the innermost enclosing namespace is the one that contains it most directly.


3.20 forward reference

A reference to a clause that appears later in the collection.

Forward references are informative navigation aids.


3.21 global namespace

The namespace containing every declaration not contained by any other namespace.

The global namespace has no name. A name in it is written with a leading ::, or with no qualification where lookup reaches it. Every entity of the standard library is in it, and so is every entity declared by an ordinary C translation unit. See clause 6.9.6.


3.22 implementation

A particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment.


3.23 implementation-defined behavior

Behavior whose result depends on a genuine property of the target or of the implementation, where the implementation shall document its choice.

Difference: ISO C99 places a large number of behaviors in this category for historical reasons. Ocean Edition I admits a behavior into this category only when supported targets genuinely differ. See clause 0.3 and behavior.md section 112.


3.24 linkage name

The name by which an entity with external linkage is known to the linker.

For an entity outside any namespace, the linkage name is the identifier. For an entity inside a namespace, it is formed by the rule in clause 6.9.6.4. An entity without external linkage has no linkage name.

ISO C99 mapping: new. In ISO C99 the linkage name is always the identifier, so the term is not needed.


3.25 lvalue

An expression with an object type or an incomplete type other than void that potentially designates an object.

A modifiable lvalue is an lvalue that does not have array type, does not have an incomplete type, is not const-qualified, and, if it is a structure or union, has no member that is const-qualified at any depth.

Difference: an array lvalue is not modifiable, but it remains an ordinary lvalue that designates the whole array object, and it is not converted to a pointer. See clause 6.3.2.1.


3.26 memory location

An object of scalar type, or a maximal sequence of adjacent bitfields all having nonzero width.

Two accesses to distinct memory locations do not interfere with each other.


3.27 namespace

A named region of declarations whose entities are reached by qualification, and whose external names are distinguished from those of every other namespace.

A namespace assigns names. It does not control visibility, which remains the business of static, and it does not describe dependency, which remains the business of the header. See clause 6.9.6.


3.28 namespace scope

The region of a namespace definition or of the part of a source file governed by a #namespace directive, in which declarations become members of that namespace.

Namespace scope is a property of a declaration's placement rather than a fifth kind of scope. A declaration at namespace scope has file scope in the sense of clause 6.2.1, and additionally has namespace membership. See clause 6.2.1.3.


3.29 object

A region of data storage in the execution environment, the contents of which can represent values.

Every object has a type, a storage duration, a lifetime, and a value. An object may have linkage. When referred to, an object may be interpreted as having a particular type. See clause 6.2.4 and behavior.md section 41.


3.30 parameter

An object declared as part of a function declaration or definition that acquires a value on entry to the function.


3.31 profile

A named set of additional restrictions an implementation offers on top of conformance.

The strict profile promotes recommended diagnostics to errors. See clause 4.6.


3.32 qualified identifier

An identifier preceded by a namespace qualification, written with ::.

net::open names open in the namespace net. ::open names open in the global namespace. See clause 6.5.1.1.


3.33 recommended practice

Guidance that is not a requirement.

Recommended practice describes what a good implementation does where the specification declines to require it.


3.34 reproducible

Of an artifact, having the property that repeating the translation with an identical translation input closure yields an identical sequence of bytes.

ISO C99 mapping: new. See clause 4.10.


3.35 scalar type

An arithmetic type, an enumeration type, or a pointer type.

Scalar types are the types that can be used directly as a condition. See clause 6.5.13.


3.36 storage duration

The property of an object that determines its lifetime.

The storage durations are automatic, static, and allocated. An implementation may provide thread storage duration as a documented extension. See clause 6.2.4.


3.37 target ABI

The application binary interface selected by the implementation for a given translation.

The target ABI determines type sizes, alignment, structure layout, bitfield allocation, calling convention, and endianness. Once an ABI is selected, no layout freedom remains. See clause 5.2.4 and behavior.md section 23.


3.38 translation input closure

The complete set of inputs that determine an artifact, listed exhaustively in Annex K clause K.3.1.

An artifact shall be a function of its translation input closure and of nothing else.


3.39 translation unit

A source file together with all headers and source files included through the #include directive, after conditional inclusion has removed the source lines that do not apply.


3.40 trap representation

An object representation that does not represent a value of the object type.

Difference: integer types in Ocean Edition I have no trap representations. Every bit pattern of an integer object represents a value. The term is retained only so that clauses can state its absence. See clause 6.2.6.2 and behavior.md section 16.


3.41 undefined behavior

Behavior for which this specification imposes no requirements at all.

Difference: Ocean Edition I does not use this category. Every construct that ISO C99 leaves undefined is placed by this edition into defined behavior, into a defined trap, or into unsafe memory behavior. The term is retained in clause 3 so that comparisons with ISO C99 have a name for what was removed, and so that clause 4.7 can prohibit its reintroduction.


3.42 unsafe memory behavior

A behavior category. The program accessed storage that does not hold a valid object of the required kind, or operated on an invalid pointer.

This is the only category in which this specification declines to predict the result. It exists because manual storage management is retained. See clause 0.3 and annex-d-defined-traps-and-unsafe-operations.md clause D.3.


3.43 unspecified behavior

Behavior where this specification permits a choice among possibilities and does not require the implementation to document which it selects.

Ocean Edition I contains very little unspecified behavior, and treats a proposal to add more as a last resort. Every instance is listed in annex-c-implementation-defined-behavior.md clause C.9. See behavior.md section 113.


3.44 value

The precise meaning of the contents of an object when interpreted as having a specific type.


3.45 value bits

The bits of an integer object representation that participate in determining its value.

Every bit of an Ocean Edition I integer object representation is a value bit. There are no padding bits in integer types. Padding may still appear inside structures and unions, between members. See clause 6.2.6.2.