1. Scope

1.1 What This Specification Specifies

This specification defines the language C, Ocean Edition I, hereafter written as Ocean Edition I where the edition needs to be distinguished from C generally.

It specifies:

• the representation of Ocean Edition I programs,
• the syntax and constraints of the language,
• the semantic rules for interpreting a program,
• the representation of input data to be processed by a program,
• the representation of output data produced by a program,
• the restrictions and limits imposed by a conforming implementation,
• the set of behaviors an implementation shall document,
• the set of operations that trap,
• the set of operations that remain unsafe,
• the requirement that translation produce reproducible artifacts, and the tooling an implementation shall provide to demonstrate it.

1.2 What This Specification Does Not Specify

This specification does not specify:

• the mechanism by which a program is transformed for use by a data-processing system, beyond the reproducibility requirement of clause 4.10,
• the mechanism by which programs are invoked,
• the mechanism by which input data are transformed for use by a program,
• the mechanism by which output data are transformed after being produced,
• the size or complexity of a program that will exceed the capacity of any specific data-processing system,
• the capacity of any single implementation,
• the internal architecture of any compiler, except where Annex K constrains an internal choice whose effect reaches an artifact,
• the choice of intermediate representation,
• the strategy used to satisfy a semantic guarantee, provided the observable result is correct and reproducible.

An implementation may be a native compiler, a bootstrap compiler, a source-to-source translator, an interpreter, a just-in-time compiler, a cross compiler, or any other conforming arrangement. See behavior.md section 1.

1.3 Derivation

Ocean Edition I is a derivative work of ISO/IEC 9899:1999.

Its text, its clause organization, its grammar, its declarator model, its library interface, and its computational model are taken from that standard and then modified. Where this specification says nothing about a construct that ISO C99 specifies, the ISO C99 rule applies, adjusted by the general rules of clause 6. This specification is not a from-scratch description of a language that resembles C. It is C99 with a normalization pass applied to it, and it is written to be read alongside the document it derives from.

The derivation is acknowledged rather than hidden. A reader holding ISO/IEC 9899:1999 should be able to work through both documents in parallel, which is why clause numbering is preserved and why every clause carries an ISO mapping line.

ISO C99 is the compatibility baseline. Ocean Edition I is neither a superset nor a subset of it.

1.3.1 How this edition differs from its baseline

Six kinds of difference exist, and every difference in the collection is one of them.

Removal

A construct that exists in ISO C99 is not part of this edition, because an existing C spelling already expresses the same operation. Nothing is removed merely because it is old or unfashionable.

Definition

A behavior that ISO C99 leaves undefined, unspecified, or implementation-defined is given a single rule, where a rule sensible on every supported target exists.

Canonicalization

Where ISO C99 accepts several spellings of one thing, one spelling is chosen.

Change

A construct produces a different result. This kind is rare, every instance is argued at its clause, and the complete list is short enough to read in one sitting.

Adoption

A facility from a C standard published after 1999 is taken into this edition. See clause 1.4.

Addition

A facility that no C standard provides is added. Exactly one facility is in this category, and clause 1.5 states the test it had to pass.

The complete difference list is in annex-g-divergences-from-c99.md.

1.4 Selective Adoption from Later C Standards

ISO C did not stop in 1999. ISO/IEC 9899:2011, 9899:2018, and 9899:2024 each contain work that solves a problem this edition also has, and refusing to look at that work on the grounds that the baseline is C99 would be a strange kind of discipline.

Ocean Edition I therefore adopts selectively from later standards. It does not adopt a later standard wholesale, and it does not track one.

1.4.1 The adoption test

A facility from a later C standard is adopted only when it passes every one of the following. The test is deliberately strict, because the baseline is a commitment rather than a starting suggestion.

1. It serves an aim this edition already has. The facility must reduce semantic categories, remove an irregularity, define something previously undefined, or replace a library workaround with a language rule. A facility that only adds capability does not qualify, and belongs in the non-goals of syntax.md section 4.

2. It does not conflict with the two white papers. A facility that contradicts ../syntax.md or ../behavior.md is rejected regardless of its merits, under clause 1.5.

3. It clears the syntax bar. Adding surface syntax requires a much higher standard than tightening semantics, under syntax.md section 5. A facility that adds a keyword must be repairing something that existing C syntax genuinely cannot express.

4. It keeps the source looking like C. A facility whose adoption would make ordinary source announce that a different language is being used is rejected, under syntax.md section 59.6.

5. It does not create gratuitous ABI incompatibility. A facility that changes the layout, size, or calling convention of an existing construct is rejected unless the change is the entire point of adopting it.

6. It is implemented and settled. A facility still being revised by the committee is not adopted. Ocean Edition I adopts conclusions rather than directions.

A facility that fails any test may still appear as a recommended extension, which is how thread storage duration, atomics, and static assertions are handled. See clause 6.11.5.

1.4.2 What adoption means

An adopted facility becomes part of this edition on this edition's terms. It is respecified in the vocabulary of clause 0.3, is subject to the same conformance and diagnostic requirements as everything else, and may be narrowed relative to the standard it came from.

Adoption is not a compatibility promise with the standard of origin. A program using an adopted facility is an Ocean Edition I program, not a C11 or C23 program.

1.4.3 What has been adopted

The complete catalogue is in annex-g-divergences-from-c99.md clause G.5. The two most visible adoptions are:

• bool, true, and false as core language constructs rather than macros in a header, from ISO/IEC 9899:2024. See clause 6.2.5.2 and clause 6.4.1.
• null and NULL as core language constructs with a distinct type, taking the substance of C23 nullptr. See clause 6.4.4.6.
• #pragma once as a required part of the language rather than a compiler detail. See clause 6.10.2.4.

1.5 Additions

1.5.1 The addition test

An addition is a facility that no C standard provides and that this edition introduces on its own account.

The bar is higher than for adoption, because an adopted facility has been designed, implemented, and used elsewhere, while an addition has not. syntax.md section 5 sets the standard: adding syntax requires a much stronger case than tightening semantics.

A facility is admitted as an addition only when it passes every one of the following.

1. It solves a problem C programmers already solve by hand. The facility shall automate an existing practice rather than introduce a new capability.

2. It produces the same result the manual practice produces. A program using the facility and a program using the convention it replaces shall be able to interoperate without a shim.

3. It introduces no new runtime concept. No new object model, no new lifetime, no new storage duration, no new control flow, and no new calling convention.

4. It lowers to existing C constructs. The facility shall be expressible in ordinary C by a mechanical rewrite, and that rewrite shall be describable in this specification.

5. It leaves the ABI unchanged. Layout, alignment, parameter passing, and linkage shall be exactly what they were.

6. It changes no existing program. Source that does not use the facility shall behave as it did before the facility existed.

7. It does not conflict with the white papers, or the white papers are amended to record the exception before the facility is admitted. See clause 1.6.

A facility failing any test is not an addition. It may still be a recommended extension under clause 6.11.5, which is a different thing and carries no conformance weight.

1.5.2 The facilities admitted

One facility is admitted under clause 1.5.1.

Namespaces. A language-level unique naming mechanism, consisting of the namespace definition form, the #namespace directive, the :: qualification operator, and the #import directive. See clause 6.9.6 and clause 6.10.11.

The record of how it passed each test is in annex-g-divergences-from-c99.md clause G.6, and the reasoning is in syntax.md section 5.1.

1.5.3 The list is closed

Clause 1.5.2 is a complete list, and this specification does not anticipate extending it.

An implementation shall not admit a facility of its own under clause 1.5.1. An implementation extension is governed by clause 4.8, which forbids it from changing anything this specification defines, and an addition by definition changes the language.

The tests exist so that a proposal can be measured rather than argued. A facility that passes all seven is close to a notation for something programmers are already doing. Most proposals fail test 1 or test 3 immediately, and that is the intended outcome.

1.6 Relationship to the White Papers

The two white papers in the parent directory are normative for design intent, and this specification is normative for detail.

Where they disagree on a rule, the white paper governs. Where a white paper leaves detail unstated and this specification supplies it, the detail here is binding.

Neither white paper is a substitute for this specification when implementing. Neither this specification nor an implementation is a substitute for the white papers when deciding whether a proposed change belongs in the edition.

1.7 Language Name

The language is named C.

The edition is named Ocean Edition I.

Source files use the ordinary C file extensions. A conforming implementation shall provide a documented way to select the edition, and shall not select it silently for source that was written as ISO C. See clause 4.6.

1.8 Audience

This specification is written for implementers first and for programmers second.

It assumes familiarity with C. It does not re-teach pointers, structures, or manual storage management, and it does not argue for the machine-oriented model it inherits. It states rules, and where a rule differs from the C a reader already knows, it says so at the point of difference.

1.9 Conformance Claims

An implementation claims conformance to this specification by satisfying clause 4 and by publishing the documentation clause 4 requires. No other claim of conformance is defined by this specification.

An implementation that supports ISO C99 alongside Ocean Edition I claims conformance to each separately. Supporting both is expected and is described in syntax.md section 58.