C (programming language)

Origins and the low-level bargain¶

C descends from a line of languages built to write compilers and operating systems on machines with a few tens of kilobytes of memory. Martin Richards’ BCPL (1967) had a single data type — the machine word — and a portable bootstrap route through an intermediate code. Ken Thompson cut BCPL down to B (1969) to fit the PDP-7. B was typeless and word-addressed, which became untenable on the byte-addressed PDP-11, so between 1971 and 1973 Ritchie added types, structures, and a preprocessor, producing C.

The decisive event was the 1973 rewrite of the Unix kernel in C. Until then, operating systems were assembly artefacts tied to one machine. A kernel written in a language that compiled to comparable code, but could be retargeted, made Unix portable, and Unix carried C with it into every research and commercial computing environment of the following decade. The 1978 first edition of Kernighan and Ritchie’s The C Programming Language served as the specification for eleven years.

What that history fixed into the language is a bargain that has never been renegotiated: the programmer states intent in terms of storage, and the implementation is not required to check that the intent was coherent. Bounds are not carried with arrays, lifetimes are not tracked, and the type of the bytes in a region is known to the compiler but not enforced at run time. In 1973 this was the only way to get an operating system out of a high-level language on a PDP-11. It remains the reason C compiles to predictable code on hardware that did not exist when the standard was written — and the reason the memory-safety debate in Trends is about C specifically.

ANSI convened X3J11 in 1983 to standardise the language against a growing set of incompatible vendor dialects; the result, C89, was adopted essentially unchanged by ISO as C90. Maintenance passed to WG14, which has held it since.

Back to top

The abstract machine¶

C is not defined in terms of a processor. It is defined in terms of an abstract machine in which expressions are evaluated in the order the semantics describe, and every operation happens. A conforming implementation must reproduce only the observable behaviour of that machine: the sequence of accesses to volatile objects, the data written to files at program termination, and the prompting output that precedes a blocking read. Anything else — a computation whose result is unused, a load that can be proved redundant, an entire loop — may be deleted, reordered, or replaced. This is the as-if rule, and it is the single most important sentence in the standard for understanding why a C program behaves the way it does.

Two consequences follow immediately and account for most surprises.

Optimisation is licensed by the absence of defined behaviour, not by the presence of it. If signed overflow were defined as wrapping, then i + 1 > i would not be reducible to 1, and a loop with an int induction variable could not be promoted to the machine’s natural word size. Because overflow is undefined, the compiler is entitled to assume it does not happen, and to generate code that is wrong only for programs that were already outside the language.

Evaluation order is far weaker than the syntax suggests. C89 expressed ordering with sequence points; C11 replaced them with the sequenced-before relation, which is a partial order. In f() + g(), the two calls are indeterminately sequenced — one runs entirely before the other, but which one is unspecified and may differ between call sites. Modifying the same scalar twice with no sequencing between the modifications is undefined, which is what makes the classic i = i++ unanswerable rather than merely unspecified.

/* Evaluation order, three distinct outcomes. */
int i = 0;
a[i] = i++;            /* undefined: unsequenced modification and use of i   */
int x = f() + g();     /* unspecified order; both complete, no interleaving  */
int y = f() && g();    /* sequenced: && sequences its left operand before    */
                       /* the right, and short-circuits                      */

/* The as-if rule, visible. Both loops are observably identical, so an
   implementation may emit the closed form for the first and nothing at
   all for the second. */
unsigned long sum = 0;
for (unsigned long k = 0; k < n; k++) sum += k;   /* -> n*(n-1)/2 */
for (unsigned long k = 0; k < n; k++) ;           /* -> deleted   */

The abstract machine is also where volatile earns its keep. It has nothing to do with threads: it marks an object whose reads and writes are themselves observable behaviour, so the implementation may not add, remove, or reorder them relative to other volatile accesses. That is exactly the guarantee a memory-mapped device register needs, and exactly not the guarantee shared mutable state between threads needs — for which see the memory model.

The bottom tier of Figure 1 is where this page stops and the hardware starts, and it is worth naming what is down there. The abstract machine has no cost model: in it, every access to every object costs the same, and on the machine underneath, accesses differ in cost by two orders of magnitude depending on where the bytes happen to be. The atlas measures that tier directly, on the memory hierarchy and retrieval page.

Back to top

Objects, storage, and representation¶

An object in C is a region of data storage whose contents can represent values. Not a class instance: a region of bytes. Every object has a size in bytes given by sizeof, an alignment requirement, a storage duration that determines when the region exists, and an effective type that determines how the bytes may lawfully be read.

The four storage durations of C23. The third column names the declaration that produces each; the fourth is a description of what implementations do, not a requirement of the standard. Source: ISO/IEC 9899:2024 §6.2.4.

The representation of an object is the sequence of sizeof bytes it occupies. That sequence may contain padding bits — between structure members to satisfy alignment, at the end of a structure so that arrays of it stay aligned, and in principle inside integer types. Padding has an indeterminate value, which is why comparing two structures with memcmp is a bug rather than a shortcut, and why a structure copied field-by-field and one copied with memcpy can differ byte for byte while holding the same values.

struct packet { unsigned char kind; unsigned int length; unsigned char flags; };
/* On a typical 32-bit-int, 4-byte-aligned target:
     offset 0  kind        1 byte
     offset 1  <padding>   3 bytes   <- indeterminate
     offset 4  length      4 bytes
     offset 8  flags       1 byte
     offset 9  <padding>   3 bytes   <- so sizeof is a multiple of alignof
   sizeof(struct packet) == 12, not 6. Neither number is required by the
   standard; offsetof and sizeof are the only portable way to ask. */

_Static_assert(sizeof(struct packet) >= 6, "no upper bound is portable");

C23 finally fixed one long-standing latitude: integers are required to use two’s complement representation, ending the standard’s formal support for sign-magnitude and ones’ complement machines. What it did not do is define signed overflow — the representation is fixed, the arithmetic remains undefined. Nor did it fix the width of int, the signedness of plain char, or the number of bits in a byte, all of which remain implementation-defined and are the reason <stdint.h> exists.

Reading an object through an lvalue of the wrong type is where the effective type rule bites. An object declared with a type has that type for its whole life; an allocated object takes its effective type from the last store into it. Access through any other type is undefined, with a short list of exemptions: a compatible type, a signed/unsigned variant, a qualified version, an aggregate containing the type, and — always — a character type. That final exemption is why serialisation code is written with unsigned char and memcpy:

/* Type punning. The union form is well defined in C (and is not in C++);
   the pointer-cast form is a strict-aliasing violation and may be
   miscompiled at -O2 with no diagnostic. */
union bits { float f; uint32_t u; };
uint32_t ok(float f)  { union bits b = { .f = f }; return b.u; }

uint32_t also_ok(float f) { uint32_t u; memcpy(&u, &f, sizeof u); return u; }

uint32_t undefined(float f) { return *(uint32_t *)&f; }   /* don't */

Padding and alignment are usually met as portability hazards, which is how they are presented above. They are also the mechanism by which a C programmer decides where bytes are, and that decision is the largest lever on how fast a program runs — larger, on the hardware C actually compiles for, than the algorithm above it. The atlas takes that apart on its memory hierarchy and retrieval page, which measures the cost of a load at every level of a real machine and then measures what rearranging the same bytes is worth: a search tree whose node is one cache line beats binary search over the same keys by more than a factor of two, at the same complexity, on the same data. One section of it is about this one: exactly what the standard gives you for controlling layout, and exactly how much of the hierarchy it declines to mention.

Back to top

Pointers, arrays, and provenance¶

A pointer in C is not an address. It is a value that may point at an object or a function, or be null, or be indeterminate, and the rules that govern it are narrower than the arithmetic that hardware would allow. Pointer arithmetic is defined only within a single array object, and a scalar counts as an array of one. A pointer may be formed one past the end of that object, but not dereferenced there, and not two past.

int a[10];
int *p = a;            /* array-to-pointer decay: p == &a[0]                 */
int *q = a + 10;       /* one past the end: forming this is legal            */
                       /* *q is not; comparing q with a+n is                 */
ptrdiff_t n = q - p;   /* 10 -- only defined within one array object         */

int b[10];
if (a + 10 == b) { }   /* unspecified: may compare equal on a flat address   */
                       /* space, and still not be interchangeable            */

/* restrict is a promise, checked by nobody. It says: for the lifetime of
   this pointer, the object it points to is reached only through it. */
void add(size_t n, float * restrict d, const float * restrict s)
{
    for (size_t i = 0; i < n; i++) d[i] += s[i];   /* vectorisable */
}

This is stricter than “an address is an integer”, and deliberately so: the difference is what lets the compiler keep an object in a register, prove two loops touch disjoint memory, or hoist a bounds computation. It also creates the problem the committee is still working on. If a pointer that happens to hold the same address as another is not interchangeable with it, the model needs to say what travels with a pointer besides its address. That extra information is called provenance, and its absence from the standard is why round-tripping a pointer through uintptr_t, comparing pointers derived from different objects, or reconstructing a pointer from bytes has no agreed meaning today. A formal provenance model developed through the C memory-object study group is the most consequential semantic change queued for the next revision; see Future outlook.

Arrays are the other half. An array is not a pointer, and the two are conflated by a single rule: in almost every context an array expression is converted to a pointer to its first element. The exceptions are sizeof, typeof, unary &, and a string literal initialising an array. The conversion is why an array parameter is a lie — void f(int a[10]) declares a pointer parameter, the 10 is documentation, and sizeof a inside f is the size of a pointer. C99 added a way to state the intent that is honoured by static analysers and by Clang’s -fbounds-safety, but not by the language itself:

void f(size_t n, int a[static n]);   /* a shall point to at least n ints */

No bound is carried at run time. That single fact — not syntax, not manual free — is the origin of the majority of the memory-safety findings discussed under Trends.

Back to top

Undefined, unspecified, implementation-defined¶

C classifies everything it does not fully specify into four kinds, and the distinctions are load-bearing. They are routinely collapsed into “undefined behaviour” in conversation, which is the source of both unwarranted panic and unwarranted complacency.

The four classes of incompletely specified behaviour. C23 lists undefined behaviour in Annex J.2 and implementation-defined behaviour in Annex J.3; both annexes are informative and explicitly not exhaustive. Source: ISO/IEC 9899:2024 §3.4 and Annex J.

The count of distinct undefined behaviours in Annex J.2 runs into the low hundreds and has grown with every revision, because each new feature brings its own preconditions. Reading that as a defect rate misses the mechanism: undefined behaviour is how the standard declines to arbitrate between implementations, and the alternative — specifying a behaviour, such as trapping or wrapping — costs code on some target.

What has changed since the 1990s is not the rules but the consequences. An optimiser that performs interprocedural range propagation will delete a null check that follows a dereference, because the dereference already asserted the pointer is non-null. The code was always undefined; the compiler only recently became clever enough to notice. This is why the practical response is tooling rather than argument: UndefinedBehaviorSanitizer and AddressSanitizer at test time, -fwrapv or -ftrapv where wrapping semantics are genuinely wanted, and static analysis in CI. The hardening table on the reference page lists the flags.

Back to top

Translation phases and linkage¶

Compilation is specified as eight ordered phases. The order matters more than it looks: it is the reason a macro cannot see a comment, a line continuation works inside a string literal, and #include is textual rather than a module import.

The eight translation phases, in order. An implementation need only behave as if they were separate; most compilers fuse phases 3 to 7 into a single pass. Source: ISO/IEC 9899:2024 §5.1.1.2.

Phase 8 introduces the model C has instead of modules. A translation unit is one source file plus everything it includes, compiled independently. Names are joined across units by linkage: external linkage puts an identifier in one shared namespace for the whole program, internal linkage (static at file scope) confines it to one unit, and no linkage covers ordinary locals. Header files are not an interface mechanism — they are text that is pasted into each unit, which is why a declaration and its definition can disagree and the error surfaces at link time or not at all.

Two corollaries define how large C projects are built. Because each unit is compiled with no knowledge of the others, cross-unit inlining requires link-time optimisation (-flto) rather than being automatic. And because the preprocessor re-reads every header in every unit, build time scales with the product of units and header size — the pressure behind precompiled headers, unity builds, and the #embed and header-unit work in the standards committees.

Back to top

Functions: the unit of code¶

A function is the only unit of executable code C has. There are no methods, no closures, no nested functions in the standard language, and no module boundary smaller than the translation unit of the previous section. Everything a C program does at run time happens inside a function body, and every function is reachable, by default, from every other translation unit in the program.

Four things constitute one: a return type, an identifier, a parameter list, and a body. The first three are the function’s type and can be stated without the fourth; that separation — declaration apart from definition — is what makes separate compilation work, and it is the only interface mechanism the language provides.

/* Declaration -- a prototype. It gives the type of the call and nothing
   else: no storage, no code. Parameter names here are documentation, and
   the compiler ignores them. */
double rect_area(double length, double width);

/* Definition -- the same type, plus a body. An identifier with external
   linkage may be declared in every translation unit and defined in
   exactly one. */
double rect_area(double length, double width)
{
    return length * width;      /* a value leaves; the parameters do not */
}

/* Call -- an expression whose type is the return type, and whose operands
   are converted as if by assignment to the parameter types. */
double area = rect_area(5.5, 3.2);          /* 17.6 */

The distinction between the three forms above is worth stating precisely, because C uses one syntax for all of them. A declaration introduces a name and its type. A prototype is a declaration that also describes the parameter types, which is what makes a call checkable. A definition is a declaration with a body, and it is also a definition of the storage the function occupies. One program may contain any number of the first two and exactly one of the third.

Return types and parameter lists¶

Because the return type and the parameter list vary independently, function types fall into four shapes. They are usually taught as a taxonomy; they are more useful read as a statement about how much of the function’s effect the type system can see.

The four shapes, by whether values cross the boundary in each direction. The fourth is the only one whose whole effect is visible in its type; the first three move information through channels the prototype does not mention. Source: ISO/IEC 9899:2024 §6.7.6.3 and §6.9.1.

Two details of the empty parameter list are worth keeping straight, because they changed recently. void f(void) has always meant “no parameters”. void f() meant, until C23, “the parameters are unspecified” — a declaration that switched argument checking off rather than asserting anything. C23 made the two spellings identical and removed old-style definitions entirely, closing the last route by which a call could go unchecked. Code written against C17 or earlier should still be read with the old meaning in mind.

main is the one function the standard describes rather than the program: it returns int, takes either (void) or (int, char *[]), and — uniquely — reaching the closing brace without a return is defined to return 0. That exemption is specific to main. In any other value-returning function, falling off the end is undefined as soon as the caller uses the value.

Declaration, definition, and where each belongs¶

A call may appear before the definition, but not before a declaration. C89 allowed a call to an undeclared function by inventing a declaration returning int, which is how a typo could become a link error rather than a compile error. C99 removed that rule along with implicit int, so a call to an undeclared identifier is a constraint violation and requires a diagnostic; C23 removed the last of the old style with it. Compilers accepted it by default for another two decades — GCC 14 and Clang 16 were the releases that finally made it an error — so a codebase that has never been built with a current compiler may still contain some.

That leaves the ordinary arrangement. A definition used in one file only is written static and needs no declaration ahead of it beyond ordering. A definition used from several files gets a prototype in a header, which every user includes, and exactly one definition in a .c file. The header is not an interface in the way a module system means it: it is text, pasted into each unit by phase 4, and if a declaration and its definition disagree the mismatch is caught at link time, or is undefined behaviour and caught by nothing. Including the header in the file that defines the function is the cheap way to have the compiler compare them.

Specifiers, qualifiers and attributes that appear on a function or its parameters, and where each one is actually checked. Three of the seven are enforced by nobody: they are promises the optimiser is entitled to believe. Source: ISO/IEC 9899:2024 §6.7.1, §6.7.4, §6.7.12.

Passing parameters¶

A parameter is an object declared by the definition, created on entry and destroyed at the return. An argument is an expression in the parentheses of a call. The teaching vocabulary calls these formal and actual parameters; the standard’s terms are more useful because they say what each one is rather than where it appears.

C has exactly one passing mechanism: the argument is evaluated, converted as if by assignment, and copied into the parameter. There is no second mechanism to choose. “Pass by reference” in C means passing a pointer by value: the pointer is copied, the object it points at is not, and the indirection is written out by hand at every use.

/* C has one parameter-passing mechanism: copy. "Pass by reference" is the
   copy of a pointer, and the indirection is written out by hand. */

void add_ten(int n)        { n += 10; }        /* modifies the copy       */
void add_ten_p(int *n)     { *n += 10; }       /* modifies the caller's   */

int v = 5;
add_ten(v);      /* v == 5  -- the parameter was a different object */
add_ten_p(&v);   /* v == 15 -- the pointer was copied; the object was not */

/* The same rule with a bigger object is a performance decision rather than
   a semantic one: a struct argument is copied in full, so a const pointer
   is the idiom for "read this, do not copy it". */
double norm(const struct matrix *m);

/* An array parameter is a pointer parameter. All four spellings declare
   the same function, and sizeof a is the size of a pointer in every one. */
void f(int *a);
void f(int a[]);
void f(int a[10]);
void f(int a[static 10]);   /* C99: a shall point to at least 10 ints.
                               A promise to the optimiser and to analysers;
                               the language still checks nothing at run time. */

Three consequences follow from “a parameter is an object”. It is assignable, so a function may use its parameters as scratch variables without the caller noticing. Its address may be taken, and that address is not the caller’s. And the argument, being an expression, is evaluated in an order that is unspecified and unsequenced with respect to the other arguments — which is why f(i++, i++) is undefined rather than merely unpredictable, and why the classification of behaviour above is the section this belongs to.

The middle actor in the figure is where the language hands off. The standard fixes that the values are copied and that one value comes back; it says nothing about which register carries the third argument or what happens to a sixteen-byte struct. That is the ABI layer below, and the atlas takes the x86-64 rules apart in measured detail on its calling conventions page — including the binding described here and what the copy costs once an aggregate stops fitting in registers.

Returning¶

A return statement returns a value, not an object. The distinction is the difference between a working function and a dangling pointer: the value is copied out before the callee’s automatic storage ends its lifetime, so returning a struct is fine and returning the address of a local is not.

/* A return statement returns a VALUE. Everything about the object it came
   from -- its address, its lifetime, its storage duration -- is left behind. */

char *bad(void)  { char buf[32]; fill(buf); return buf; }   /* dangling: buf
                                     died at the return; the pointer outlived it */

struct point far(void) { struct point p = {1, 2}; return p; }  /* fine: the
                                     struct is copied out, member by member */

/* An array cannot be returned at all -- not a limitation of the ABI but of
   the type system: there is no array-valued expression to return. The three
   ways round it are the three lifetimes a caller can be handed. */
void   into_caller(size_t n, int out[static n]);    /* caller owns the storage */
int   *from_heap(size_t n);                         /* callee allocates; caller frees */
struct vec3 by_value(void);                         /* wrap it in a struct */

/* Falling off the end of a value-returning function is not an error the
   compiler must diagnose. It is undefined behaviour only if the caller
   uses the value -- which is why -Wreturn-type is not optional. */
int maybe(int x) { if (x > 0) return 1; }           /* undefined for x <= 0 */

Arrays are the omission people notice first. A function cannot return one, because there is no array-valued expression for it to return — the same decay rule that makes an array parameter a pointer. The three replacements in the code above are not stylistic variants: each hands the caller a different lifetime, and choosing between them is the whole of C’s ownership design, made at every interface and recorded nowhere the compiler can check.

Recursion and the stack¶

Automatic storage duration is per invocation, not per function, so recursion needs no special support: a function that calls itself gets a fresh set of objects each time, and the pending calls form a chain that unwinds in reverse.

/* Every call creates a fresh set of automatic objects, which is the whole
   of what recursion needs: the language does not have to do anything special
   for a function to call itself. */
unsigned long long fact(unsigned n)
{
    if (n < 2) return 1;            /* base case: the only exit */
    return n * fact(n - 1);         /* one live frame per pending call */
}

/* What the standard does not give is a bound. There is no minimum recursion
   depth, no diagnostic on exceeding it, and no defined behaviour once it is
   exceeded: stack exhaustion is undefined behaviour, not an exception.
   Nor is elimination of the tail call guaranteed -- compilers do it at -O2
   and are not required to, so a depth that works in a release build can
   overflow in a debug build. */
unsigned long long fact_iter(unsigned n)
{
    unsigned long long r = 1;
    while (n > 1) r *= n--;
    return r;                        /* one frame, whatever n is */
}

What the language does not supply is a bound. There is no minimum guaranteed recursion depth, no diagnostic when it is exceeded, and no defined behaviour past that point: stack exhaustion is undefined behaviour, and on most hosted implementations it arrives as a signal rather than an error the program can handle. Nor is tail-call elimination guaranteed, so a recursion that survives at -O2 may overflow at -O0. Recursion in C is a statement about clarity, and depth is a resource the programmer has to reason about unaided — which is why kernel and embedded coding standards such as MISRA C ban it outright.

Function pointers and indirect calls¶

A function is not a value in C: it cannot be assigned, stored, or passed. A pointer to one can be, and the conversion from function to pointer happens implicitly almost everywhere, which is why cmp, &cmp, and *cmp all denote the same thing in a call.

/* A function is not a value in C. A pointer to one is, and the conversion
   is automatic in almost every context -- which is why all four of these
   call the same function. */
int cmp(const void *a, const void *b);

int (*p)(const void *, const void *) = cmp;   /* &cmp is the same value */
p(x, y); (*p)(x, y); (**p)(x, y); (***p)(x, y);

/* The dispatch table is the reason the type exists: it is C's vtable, its
   plugin interface, and the shape of every callback in the standard library. */
struct op { const char *name; int (*apply)(int, int); };
static const struct op ops[] = { {"add", add}, {"mul", mul} };

/* Calling through a pointer whose type is not compatible with the
   function's own is undefined -- including a cast that merely drops a
   parameter. This is a real bug class in callback registration. */
void (*handler)(void) = (void (*)(void))takes_an_int;   /* do not */

This one type carries all of C’s dynamic dispatch. A struct of function pointers is what a driver model, a plugin interface, a virtual method table, and the qsort comparator all are; C++ virtual functions and Objective-C message sends are elaborations of it rather than departures from it. The reading rule for the declarations is on the reference page under reading a declaration, because the syntax is the one part of C that genuinely cannot be read left to right.

Variadic functions¶

A parameter list ending in ... accepts arguments the prototype does not describe. Those arguments are not converted to a parameter type, because there is no parameter to convert them to; they get the default argument promotions instead, and the callee asserts a type for each one as it reads it.

#include <stdarg.h>

/* A variadic function's extra arguments are not described by the prototype,
   so they are not checked and not converted to a parameter type. They get
   the default argument promotions instead: float becomes double, and
   anything narrower than int becomes int. */
int sum(int count, ...)
{
    va_list ap;
    va_start(ap, count);            /* C23 also allows va_start(ap) */
    int total = 0;
    for (int i = 0; i < count; i++)
        total += va_arg(ap, int);   /* the type is asserted, not discovered */
    va_end(ap);
    return total;
}

sum(3, 1, 2, 3);        /* 6                                              */
sum(3, 1, 2);           /* undefined: va_arg past the last argument       */
sum(3, 1.0, 2.0, 3.0);  /* undefined: the doubles are read back as ints   */

Nothing about that assertion is checked. The count and the types travel out of band — in a leading count, a sentinel, or a format string — and a mismatch is undefined behaviour, which is the mechanism behind the format-string vulnerability class. The practical mitigation is not in the language: __attribute__((format(printf, ...))), honoured by GCC and Clang, teaches the compiler to check a variadic function’s format argument the way it checks printf’s. C23 softened one edge by allowing va_start with no second argument, and, for the fixed-parameter case, _Generic and macros now cover a good deal of what variadic functions were reached for — see C23.

Variadic calls are also the one place where a function’s ABI differs from its non-variadic equivalent: System V requires the caller to record the number of vector registers used, and Microsoft x64 duplicates a floating-point argument into the integer register of the same slot. The calling conventions page derives both from the same assignment rule.

Back to top

The ABI layer, where the language stops¶

Nothing in the C standard says which register an argument arrives in, how a structure is laid out, or what a symbol is called in an object file. All of that belongs to the platform’s processor-specific application binary interface. The standard defines source compatibility; the psABI defines binary compatibility; the two are routinely confused, and only the second determines whether a library compiled last year still links today.

The calling conventions a portable C project most often meets. Every row is specified by a separate document maintained outside ISO. Source: the System V AMD64 psABI, Microsoft x64 calling-convention documentation, Arm AAPCS64, and the RISC-V psABI specification.

C’s accidental monopoly follows from one property: it has no name mangling and no runtime of its own. A C function is a symbol and a calling sequence, both of which any language can produce. That is why the foreign-function interface of Python, Java, Go, Rust, Swift, Lua, Ruby, JavaScript engines, and the system-call layer of every mainstream operating system is specified in C, and why extern "C" exists in C++. When two languages that are not C need to talk, they usually agree to speak C at the boundary. Rust’s repr(C), Swift’s importer, Go’s cgo, and WebAssembly’s component-model tooling are all shaped by that decision.

The atlas takes this apart in detail on its calling conventions page, which reads the System V and Microsoft x64 assignment rules off compiled output rather than restating them: the eightbyte classification as a join over an ordered chain, and the measured cost of leaving the register path. What follows here is only what the language itself fixes.

The corollary is that the C ABI is a constraint on the C standard itself. A change that would alter struct layout or argument passing cannot be adopted, however desirable, because it would silently break every binary that already exists — which is a large part of why the language evolves as slowly as the lineage below shows.

Back to top

The memory model since C11¶

Before C11, threads were entirely outside the language: POSIX threads were a library, and the guarantees that made pthread_mutex_lock work were assertions by the platform rather than the compiler. C11 imported the C++11 memory model, giving the abstract machine a definition of data race — two conflicting accesses to the same object, at least one a write, neither atomic, with no happens-before between them — and declaring it undefined behaviour.

#include <stdatomic.h>
#include <threads.h>

static atomic_int ready = 0;
static int payload;                 /* plain, non-atomic */

int producer(void *unused)
{
    payload = compute();                                  /* (1) */
    atomic_store_explicit(&ready, 1, memory_order_release);/* (2) publishes (1) */
    return 0;
}

int consumer(void *unused)
{
    while (!atomic_load_explicit(&ready, memory_order_acquire))
        thrd_yield();
    use(payload);                   /* well defined: (2) synchronises with this */
    return 0;
}

The memory orders of <stdatomic.h>. Colour is not used here because these are not ranked: a stronger order is not a better one, it is a more expensive one. Source: ISO/IEC 9899:2024 §7.17.3.

The primitives built on that model — condition variables, the difference between a mutex, a semaphore and a spinlock, deadlock prevention, lock-free structures and the cache effects that dominate all of them — are taken apart with measurements on the atlas’s synchronisation page. Three of the usual rules of thumb do not survive the measurement.

Two practical caveats. <threads.h> is a conditional feature: an implementation may define __STDC_NO_THREADS__ and omit it, which several have, so portable code still reaches for pthreads or Win32 threads. And atomics carry the same optionality flag, __STDC_NO_ATOMICS__ — though in practice every hosted implementation of note provides both. What the model unambiguously gave the ecosystem is a shared vocabulary: the same acquire/release semantics now appear in C, C++, Rust, and the Linux kernel’s own documented model, which made cross-language lock-free code reviewable for the first time.

Back to top

The standard lineage¶

C is standardised by ISO/IEC JTC1/SC22/WG14. A revision is prepared as a working draft, balloted as a committee draft, and published; between revisions, defects are answered by published defect reports that a later revision folds in. Every revision so far has been very nearly backward compatible, and the few removals have been of constructs already marked obsolescent for a decade or more.

The six published revisions, plus the pre-standard baseline. Keyword and header counts are as listed in each revision’s own text. Source: ISO/IEC 9899:1990, its 1995 amendment, 9899:1999, 9899:2011, 9899:2018, and 9899:2024.

Two revisions deserve separate mention. C99 is the one the ecosystem took longest to absorb: variable-length arrays and complex arithmetic — whose Annex G semantics the atlas takes apart on its complex arithmetic page — were expensive enough that C11 demoted both to optional features, and Microsoft’s compiler did not offer a usable C99 mode until 2013. C17 added nothing — it exists to publish accumulated defect resolutions — yet it remained the default language mode of the major compilers for years afterwards — GCC switched its default to gnu23 only in GCC 15 (2025), and Clang and MSVC still default to a C17-era mode. The practical baseline for portable code today is therefore C17 with selected C23 features guarded by __STDC_VERSION__ or __has_include.

Back to top

C23: the current standard¶

C23 was published as ISO/IEC 9899:2024 on 31 October 2024 — the designation and the publication year differ because the revision was named for its intended year. It is the largest feature release since C99, and its through-line is convergence: most of what it adds either already existed as a compiler extension or already existed in C++, and the committee standardised the existing spelling rather than inventing a new one.

C23 by area. The list is representative rather than complete; the revision also folds in every defect report resolved since C17. Source: ISO/IEC 9899:2024, and working draft N3220 for clause numbering.

#include <stdbit.h>
#include <stdckdint.h>

constexpr int header_len = 8;             /* a constant, not a macro       */

typeof(header_len) copy = header_len;     /* deduced without naming int    */

static const unsigned char logo[] = {
#embed "logo.png"                          /* the file, as initialisers     */
};

[[nodiscard]] bool try_grow(size_t n, size_t elem, size_t *out)
{
    return !ckd_mul(out, n, elem);        /* true on success, no overflow   */
}

int leading = stdc_leading_zeros(0b0001'0000u);   /* 27 on a 32-bit uint    */

Availability, not publication, is what determines whether a feature is usable. GCC has implemented the bulk of C23 since GCC 13–15 and defaults to gnu23 from GCC 15; Clang has landed most of it across Clang 16–19 while still defaulting to a C17-era mode; MSVC ships a subset under /std:clatest. Embedded toolchains lag by years, and safety-critical projects are frequently pinned to C99 or C11 by their certification evidence. The realistic reading in 2026 is that C23 is the standard, C17 is the deployed default, and a portable file that wants C23 features tests for them:

#if __STDC_VERSION__ >= 202311L
  /* C23: bool, nullptr, [[nodiscard]] are all available */
#elif __STDC_VERSION__ >= 201112L
  #include <stdbool.h>
#endif

Back to top

Dialects, subsets, and freestanding C¶

Almost no large C program is written in strictly conforming ISO C. It is written in a dialect: the ISO language plus a set of compiler extensions, minus a set of constructs banned by a coding standard. Both directions matter, and they are not symmetric — the extensions are what makes systems programming practical, and the bans are what makes it auditable.

The dialects a working C programmer meets. Rows are not mutually exclusive: the Linux kernel is freestanding GNU C, and an automotive project may be MISRA-constrained freestanding C compiled by a vendor toolchain. Source: GCC and Clang extension documentation, MISRA C:2023, the SEI CERT C Coding Standard, and ISO/IEC 9899:2024 §4.

Hosted versus freestanding is the standard’s own division, and it is the one that most changes what C means in practice. A hosted implementation provides the whole library and starts at main. A freestanding implementation must provide only the headers that declare no functions — <float.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and a handful added since — and the entry point is whatever the platform says it is. Every kernel, every bootloader, and every microcontroller image is freestanding C.

The other divergence worth naming is C against C++. They stopped being a subset relationship long ago: C has designated initialisers, restrict-qualified pointers, variably modified types, and union type punning that C++ lacks or forbids; C++ has everything from overloading to templates that C does not parse. The shared surface is the ABI and the preprocessor, which is exactly the surface that extern "C" preserves. C23 narrowed some of the gap deliberately — attributes, nullptr, constexpr, bool — by adopting C++ spellings.

Back to top

The tree C produced¶

C’s influence runs along four separate channels that are usually conflated. Syntax is the most visible and the least consequential; the ABI is the least visible and the most consequential.

How C propagates. A language can appear in more than one row: Rust reacts against C’s aliasing model, is bootstrapped through LLVM rather than C, and still exposes a C-compatible ABI. Source: language specifications and reference implementations as cited on each language’s record page.

The fifth channel has no arrows on any diagram: C is the language in which the interfaces of the computing platform are written. POSIX, Win32, OpenGL and Vulkan, SQLite, zlib, OpenSSL, libcurl, the Linux system-call layer, and the CUDA and OpenCL host APIs are all specified as C headers. A language that wants to use any of them must be able to read a C declaration and honour a C calling convention, whatever else it does. That is why C’s share of new code and C’s importance to the ecosystem have been diverging for twenty years without contradiction.

Back to top

Compilers, libraries, and tooling¶

C has no reference implementation. The standard is the reference, and every implementation is a peer, which is why conformance is discussed in terms of documented deviations rather than compatibility with a canonical compiler.

The compilers a portable C project is realistically built with. Source: GCC and LLVM release notes and C-status pages, Microsoft C language conformance documentation, and each vendor’s product documentation.

The library is a second, independent axis. The standard library is small; what a program actually links is a C library implementation whose POSIX surface, threading model, and symbol-versioning policy vary considerably.

The C library implementations in common use. Choice of libc affects binary portability far more than choice of compiler: a glibc-linked binary generally will not run against musl and vice versa. Source: project documentation for each implementation.

Tooling is where the last fifteen years of C practice actually changed. The compiler is now the smallest part of the loop: AddressSanitizer, UndefinedBehaviorSanitizer, ThreadSanitizer and MemorySanitizer for dynamic checking; Valgrind where a rebuild is not possible; clang-tidy, Coverity, PVS-Studio and the GCC static analyser for whole-program inspection; libFuzzer, AFL++ and OSS-Fuzz for coverage-guided fuzzing; and CMake, Meson or Bazel over what was, for two decades, hand-written Make. The reference page lists the flags each of these needs.

Back to top

Where C actually runs¶

C’s position is unusual and is misread in both directions. It is not a growing language by any measure of new projects, and it is not a declining one by any measure of code executed. Both statements are true because they measure different populations.

Where C is the working language rather than a legacy constraint. Source: project documentation and source trees of the named systems.

Popularity signals and their blind spots. Each row states a claim that holds across editions rather than a rank from one of them, because these figures move month to month and a quoted number dates the page the day it is published; the current edition of each index is the place to read a number. Source: the TIOBE index, the annual Stack Overflow Developer Survey, GitHub’s Octoverse reports, and Linux kernel release statistics.

The pattern behind every row is the same. C is chosen when the code must run with no runtime beneath it, when it must be callable from everything, when the target has kilobytes rather than megabytes, or when it already exists and works. It is not chosen for new application software, and has not been for twenty years.

Back to top

Trends¶

One subject dominates the current discussion of C, and it is not a language feature. The question is whether code written in a language with unchecked memory access can continue to sit under critical infrastructure, and the pressure is arriving through regulation and procurement rather than through language design.

The forces acting on C in 2026. Rows one and two are external findings; rows three to five are responses within the C ecosystem. Source: CISA and international partner guidance on memory-safe roadmaps, the US ONCD report on secure building blocks, EU Regulation 2024/2847 (Cyber Resilience Act), published Android and Chromium vulnerability analyses, LLVM documentation for -fbounds-safety, and the Rust for Linux documentation in the kernel tree.

What has not happened is equally informative. There has been no large-scale rewrite of kernels, databases or media libraries, no fork of the language, and no committee move to make C safe by default — which would break the ABI and the installed base at once. The realistic trajectory is stratified: new code at the edges moves to memory-safe languages, existing C is hardened with flags and sanitizers, the most exposed parsers are replaced individually, and the C that remains is the part where the alternative does not exist.

Back to top

Future outlook¶

The next revision is designated C2y. Its contents are not final: items below have been voted into the working draft or are being pursued as separate technical specifications, and either may change before publication. WG14 has not fixed a publication date, and the working pattern since C99 suggests the latter part of this decade. Anything in this section should be checked against the current WG14 document log rather than relied on.

Work in progress for C2y and its associated technical specifications, as of the public working drafts. Provisional in every respect. Source: the WG14 document register at open-std.org/jtc1/sc22/wg14 and the published C2y working draft.

The deeper constraint on all of it is the one named under the ABI layer: C cannot adopt a change that alters layout or calling convention, and it cannot adopt a change that invalidates code written against a thirty-year-old standard, because both properties are the reason systems are written in C in the first place. That rules out most of what would make the language safe, and leaves additive, opt-in mechanisms — annotations, checked-arithmetic library functions, a provenance model that codifies what compilers already assume.

A structured forecast, stated so it can be checked against later. These are the atlas’s assessments, drawn from the sources cited elsewhere on this page, not claims made by WG14.

The summary judgement: C is finished as a growth language and unfinished as an artefact. Its floor — the ABI, the system interface, the freestanding target — is not under threat from any current alternative, because every current alternative is built on it. Its ceiling is set by the memory-safety argument, which it will answer with tooling, hardening and opt-in annotations rather than with a new language. Expect the next decade of C to be about checking C, not about writing more of it.

Back to top

References and sources¶