0. Conventions of This Specification

0.1 Purpose of This Clause

This clause fixes the vocabulary and notation used by every other document in the collection. It is normative. A rule stated here applies everywhere unless a later clause explicitly narrows it.

0.2 Normative Verbs

The specification uses a small set of verbs with fixed meanings.

shall

States a requirement. An implementation that does not meet a shall requirement does not conform. A program that violates a shall requirement placed on programs is invalid, and the implementation is required to diagnose it unless the clause says otherwise.

shall not

States a prohibition with the same force as shall.

should

States a strong recommendation. An implementation that ignores a should still conforms, but the recommendation exists because ignoring it produces a worse language experience for no compensating benefit.

should not

States a strong discouragement with the same force as should.

may

States permission. A may never creates an obligation on a program or on an implementation.

can

States a possibility or a capability. It is descriptive rather than permissive.

is, are, has

State a definition or a fact about the language. A defining sentence carries the same force as shall.

0.3 Behavior Categories

Ocean Edition I recognizes four categories of behavior. Traditional C recognizes five. The difference is the point of the edition.

Defined behavior

The specification determines the result. Every program construct not placed in another category has defined behavior.

Implementation-defined behavior

The result depends on a genuine property of the target or of the implementation. The implementation shall document the choice it makes. Every instance in this specification is catalogued in annex-c-implementation-defined-behavior.md.

An implementation-defined behavior shall correspond to a real difference between real targets. Historical indecision is not a target property.

Defined trap

The operation cannot produce a valid result. Execution stops through the implementation's documented trap mechanism, at the point of the operation, with the effects of previously completed operations intact. Every instance is catalogued in annex-d-defined-traps-and-unsafe-operations.md.

Unsafe memory behavior

The program accessed storage that does not hold a valid object of the required kind, or operated on an invalid pointer. The result is not predicted by this specification. This category exists because Ocean Edition I remains a manually managed systems language, and it is the only category in which the specification declines to say what happens.

There is no fifth category. In particular there is no general category of undefined behavior available to implementations as a source of optimization facts. See 04-conformance.md clause 4.7.

Unspecified behavior

Traditional C uses this term for a choice among several results where the implementation need not document which one it picks. Ocean Edition I contains very little of it. Where this specification permits a choice without requiring documentation, the clause says so in those words, and the instance is listed in annex-c-implementation-defined-behavior.md clause C.9.

0.4 Clause Structure

Each language clause is written in a fixed order so that a reader can skip to the part they need.

Statement

The rule itself, written as plainly as the subject allows.

Constraints

Requirements on programs that an implementation shall diagnose at translation time. A constraint violation is a translation error.

Semantics

What a conforming construct means at execution time.

Diagnostics

Additional diagnostics the implementation shall or should produce. Required diagnostics are collected in annex-i-diagnostics.md.

Examples

Illustrations. Examples are informative. If an example contradicts the rule above it, the rule wins and the example is a defect.

Design note

Explanation of why the rule is what it is, usually with a pointer into a white paper section. Design notes are informative.

Not every clause needs every part. Parts that would be empty are omitted rather than written as "none".

0.5 ISO Mapping Lines

Every document begins with an ISO C99 mapping line, and clauses that correspond to a specific ISO subclause repeat the mapping locally. The mapping is a navigation aid. It is informative and never changes what a clause requires.

Three mapping annotations appear:

• a subclause number, meaning that Ocean Edition I specifies the same subject,
• removed, meaning that the construct is not part of this edition, with the replacement spelling given,
• new, meaning that Ocean Edition I specifies something ISO C99 leaves open.

0.6 Grammar Notation

Grammar is written in the same style ISO/IEC 9899 uses, with two readability changes.

A nonterminal is written in italics in prose and in plain text inside grammar blocks. A terminal is written in a code span.

Within a grammar block:

name:
	alternative-one
	alternative-two

means that name is either alternative-one or alternative-two. Each alternative appears on its own line, indented by one tab.

An element followed by opt is optional:

declaration:
	declaration-specifiers init-declarator-list-opt ;

A repetition is written by recursion rather than by a repetition operator, matching ISO practice:

argument-expression-list:
	assignment-expression
	argument-expression-list , assignment-expression

The complete grammar is collected in annex-a-grammar.md. Where a grammar fragment inside a language clause disagrees with Annex A, Annex A wins, because Annex A is the copy an implementation is expected to transcribe.

ISO C99 mapping: 6.1.

0.7 Code Examples

Example code is written in the house style of the edition:

• one tab per indentation level,
• opening brace on its own line for functions, control structures, and aggregate definitions,
• trailing comma on the last element of a multi-line initializer.

House style is not a language rule. An implementation shall not reject source because of its layout.

struct Point
{
	int x;
	int y;
};

static int distance_squared(const struct Point *p)
{
	return p->x * p->x + p->y * p->y;
}

0.8 Placeholders in Prose

Where a clause needs to talk about an arbitrary type or object, it uses these names consistently:

0.9 Cross References

A reference of the form "clause 6.5.3" refers to a numbered clause anywhere in this collection. A reference of the form "behavior.md section 57" refers to a numbered section of a white paper. A reference of the form "ISO C99 6.5.16.1" refers to the international standard.

Forward references are permitted and are not a defect. The language is not layered in a way that allows every subject to be introduced before it is used.

0.10 Units

Sizes are given in bytes unless stated otherwise. A byte is eight bits in every Ocean Edition I implementation; see clause 6.2.6.1.

Widths of integer types are given in bits and always count value bits, because Ocean Edition I integer types have no padding bits.