Annex G. Divergences from ISO C99

G.0 How to Use This Annex

This is the complete list of differences between ISO C99 and Ocean Edition I. It is informative, and every entry points at the normative clause that governs.

Ocean Edition I derives from ISO C99, as clause 1.3 states. The differences fall into six kinds:

Removed. A construct ISO C99 has that this edition does not. In every case an existing C spelling already expresses the operation.

Defined. A behavior ISO C99 leaves undefined, unspecified, or implementation-defined that this edition gives one rule.

Canonicalized. A construct ISO C99 spells several ways that this edition spells one way.

Changed. A behavior that differs in result. This kind is rare and each instance is argued at its clause.

Adopted. A facility taken from a C standard published after 1999, or from settled practice that no standard has specified. Each adoption passes the test in clause 1.4.1.

Added. A facility no C standard provides. Exactly one exists, it passes the stricter test in clause 1.5.1, and clause G.6 records how.

G.1 Removed

Note on what was not removed. goto, assignment expressions, the comma operator, compound literals, designated initializers, flexible array members, bitfields, unions, separate name spaces, C declarators, typedef, function pointers, and octal constants are all retained. The question was never whether a construct is old or unfashionable. The question is whether its rules are coherent. See syntax.md section 45.

G.2 Defined

G.2.1 Arithmetic

G.2.2 Evaluation

G.2.3 Objects and storage

G.2.4 Declarations and diagnostics

G.2.5 Library

G.3 Canonicalized

G.4 Changed

These are the entries where a conforming ISO C99 program produces a different result under Ocean Edition I. There are five, and each is argued at its clause.

G.4.1 Mixed signed and unsigned comparison

-1 < 1u

is false in ISO C99 and true in Ocean Edition I. Comparison operators compare mathematical values. Clause 6.3.1.7.

Arithmetic operators are unchanged, so -1 + 1u still produces a large unsigned value, and clause 6.3.1.6 requires a diagnostic for it.

G.4.2 String literal type

sizeof("hello")

is unchanged at 6, but the type is const char [6] rather than char [6], so assigning a literal to a plain char * is now an error. Clause 6.4.5.

G.4.3 strncpy termination

strncpy always null-terminates and no longer pads the destination. The traditional behavior is available as strncpy_padded. Clause 7.2.19.

G.4.4 The integer constant zero in pointer position

int *p = 0;
if (p == 0)

are constraint violations. Write null or NULL. Clause 6.4.4.6.

A related consequence is that NULL can no longer be assigned to an integer, so int n = NULL; stops compiling. Both changes catch code that was relying on a literal zero meaning two different things.

G.4.5 Default initialization

An automatic object with no initializer reads as zero rather than as whatever was in the storage. A program that depended on the previous contents was already relying on undefined behavior, so this is a change in result only for programs that were already broken. Clause 6.7.9.2.

G.5 Adopted

Every entry here comes from a source cited in clause 2.4, and each passed the adoption test of clause 1.4.1. An adopted facility is respecified on this edition's terms, so the rule that governs is the Ocean Edition I clause rather than the standard of origin.

G.5.1 From ISO/IEC 9899:2024

Ocean Edition I goes further than C23 on the null constant as well. C23 adds nullptr while retaining NULL as a macro and retaining integer 0 as a null pointer constant, so it has three ways to write a null pointer. This edition has one constant with two spellings, and integer 0 is not among them.

Ocean Edition I goes further than C23 on the last three of the rows above. C23 removed trigraphs and K&R definitions, and this edition also removes the empty parameter list, which C23 retains. C23 requires two's complement and still permits padding bits and trap representations, which this edition does not.

G.5.2 From ISO/IEC 9899:2011

The last row is not an adoption. It records that where an implementation chooses to provide one of these, it should use the C11 spelling rather than invent one. Clause 1.4.2 explains the distinction.

G.5.3 From settled practice

G.5.4 What was considered and not adopted

These are the near misses, recorded so that the adoption test can be seen working rather than merely stated.

G.6 Added

One facility is in this category: namespaces, comprising the namespace definition form, the #namespace directive, the :: qualification operator, and the #import directive.

It is the only surface syntax this edition adds. syntax.md section 5.1 records the decision, and clause 1.5.1 states the test.

G.6.1 What it consists of

G.6.2 How it passes the addition test

Test 1, it solves a problem C programmers already solve by hand. Every large C program invents a prefix convention. net_socket_open is a namespace written by hand, spelled by agreement, and invisible to the compiler.

Test 2, it produces the same result the manual practice produces. net::open has the linkage name net__open. A C translation unit declares int net__open(const char *); and calls it. No shim, no wrapper, no attribute. See clause 6.9.6.5.

Test 3, it introduces no new runtime concept. No object model, no lifetime, no storage duration, no control flow, no calling convention. Clause 6.9.6.3 lists what membership does not affect.

Test 4, it lowers to existing C constructs. Removing the namespace and renaming each member to its linkage name produces an equivalent C program.

#import lowers to #include with two mechanical adjustments: an include guard is added to any imported header that lacks one, which reproduces idempotency, and any macro the header relied on receiving from its own imports is obtained by the corresponding #include at the top of the header, which self-contained headers already satisfy under clause 6.10.11.2.

The one behavior that does not survive the rewrite is the macro isolation of clause 6.10.11.2. A lowered header sees the includer's macros again. This is a loss of a guarantee rather than a change of meaning for any header that does not inspect macros it never defined, which is what a self-contained header is. A header that does inspect them is not mechanically lowerable, and clause H.2 says so. Annex H clause H.2 gives the full rewrite.

Test 5, it leaves the ABI unchanged. Layout, alignment, parameter passing, and linkage are untouched. Only the spelling of an external name changes, and that spelling is an ordinary C identifier.

Test 6, it changes no existing program. Source declaring no namespace is entirely in the global namespace and behaves as it did.

Test 7, it conflicts with the white papers, so they were amended first. syntax.md section 5 listed import among vocabulary the edition should not need, and section 53 declined to invent import syntax. Section 5.1 now records the exception, and sections 4 and 53 point at it. Clause 6.11.3 released import from the reserved list and kept module and export reserved.

G.6.3 What was deliberately left out

The facility is a naming mechanism, and everything that would make it a module system was excluded.

G.6.4 The cost

Two restrictions are the price of an injective, writable mangling.

Consecutive underscores are reserved. A namespace name, and an exported identifier inside a namespace, shall not contain __. Otherwise a::b__c and a__b::c collide. Clause 6.4.2.0.

A C library may collide. A C library exporting net__open collides with net::open. The mapping is injective within this edition and cannot police another language. An implementation diagnoses what it can see, and the residual risk is the one the prefix convention already carries. Clause 6.9.6.7.

G.7 Programs That Behave Identically

A program that satisfies all of the following behaves identically under ISO C99 and Ocean Edition I:

• it declares every function with a complete prototype,
• it writes &array[0] and &function where a pointer is wanted,
• it does not rely on signed overflow, on out-of-range shifts, or on division by zero,
• it does not depend on evaluation order,
• it initializes every object before reading it,
• it does not compare a signed value with an unsigned value of equal or greater rank,
• it writes NULL rather than a bare 0 in pointer position, and does not assign NULL to an integer,
• it does not use variable-length arrays, register, auto, K&R definitions, tentative definitions, or multi-character constants,
• it treats string literals as immutable.

That description fits a large fraction of carefully written modern C, which is the point. Most of what this edition requires is what a careful C programmer already does. What changes is that the compiler now agrees.