C reference

Toolchain and command line¶

GCC and Clang share their option surface almost exactly; MSVC does not. The rows below are the options that change the meaning of a build rather than its speed.

Driver options in common use. GCC and Clang accept all of the Unix-form options listed; the MSVC equivalents differ in both spelling and default. Source: GCC and Clang command-line documentation and the MSVC compiler options reference.

# A build that catches what a build can catch, before the sanitizers run.
cc -std=c23 -Wall -Wextra -Wpedantic -Werror \
   -O2 -g -D_FORTIFY_SOURCE=3 -fstack-protector-strong \
   -fno-common -Wconversion -Wshadow \
   -o app main.c util.c

Back to top

Language modes and feature tests¶

Selecting a language mode, and the macro value that identifies it. The gnu* variants of each option enable GNU extensions on top of the same standard. Source: GCC and Clang option documentation; ISO/IEC 9899:2024 §6.10.10.

Predefined macros used to compile the same source against several revisions and implementations. Source: ISO/IEC 9899:2024 §6.10.10.

#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L
  typedef typeof(0) counter;             /* C23 */
#else
  #include <stdbool.h>                   /* C99/C11: bool is a macro */
  typedef int counter;
#endif

#if !defined(__STDC_HOSTED__) || !__STDC_HOSTED__
  #define LOG(...) ((void)0)             /* freestanding: no stdio */
#endif

Back to top

Keywords by revision¶

Each revision only adds. No keyword has ever been removed, which is why a 1990 source file still parses: the cost is paid in the underscore-capital spellings, chosen precisely because no conforming program could already have used them as identifiers.

The keyword set, cumulative. C23’s 59 entries include the fourteen underscore-prefixed spellings retained from C99 and C11 plus _BitInt. These counts are the source of the chart in the article’s standard lineage. Source: ISO/IEC 9899:2024 §6.4.1 and the corresponding clause of each earlier revision.

Back to top

Types, limits, and fixed-width integers¶

C guarantees minimum ranges, not sizes. The exact-width types in <stdint.h> exist for code that needs a layout; the least- and fast- families exist for code that needs a range and should not fail to compile on a target without that exact width.

Types and their guarantees. Sizes described as ‘in practice’ are what mainstream 64-bit targets do, not requirements. Source: ISO/IEC 9899:2024 §6.2.5, §7.20 and <limits.h>.

/* Integer promotion and the usual arithmetic conversions, in three lines
   that surprise everyone once. */
unsigned char a = 200, b = 200;
int c = a + b;                 /* 400: both promote to int before adding    */

int i = -1;
unsigned u = 1;
if (i < u) { /* not taken */ } /* i converts to unsigned: 4294967295 < 1    */

char x = 'A';
printf("%zu\n", sizeof x);     /* 1 */
printf("%zu\n", sizeof +x);    /* 4: unary + promotes                      */

Two rules generate most integer bugs. Integer promotion converts anything narrower than int to int before arithmetic. The usual arithmetic conversions then bring both operands to a common type, and when the operands have the same rank but different signedness, the unsigned type wins. Signed overflow is undefined; unsigned arithmetic wraps by definition. C23’s <stdckdint.h> is the first standard facility for detecting the former without invoking it.

Back to top

Operators and precedence¶

Sixteen levels, highest binding first. Two of them are historical accidents that still cause bugs and are flagged in the notes: shift binds looser than addition, and the bitwise operators bind looser than the equality operators.

Operator precedence and associativity. The levels are a conventional rendering of the grammar in §6.5, which expresses precedence through nested production rules rather than a table. Precedence governs parsing only: except for &&, ||, ?: and ,, it says nothing about evaluation order. Source: ISO/IEC 9899:2024 §6.5.

Back to top

Reading a declaration¶

C declarations mirror use: the declaration of p is written as the expression that yields the base type. Read from the identifier, then right, then left, honouring parentheses.

Function declarators are where the rule earns its keep, because a function pointer, a function returning a pointer, and an array of function pointers differ only in where the parentheses sit. What each one is for — dispatch tables, callbacks, and the reason a function is not itself a value — is in the article, under function pointers and indirect calls.

The declarations that are misread most often. typedef exists largely to stop the last three rows from nesting. Source: ISO/IEC 9899:2024 §6.7.6.

/* The same type, twice: once inline, once via typedef. */
void (*signal(int sig, void (*handler)(int)))(int);

typedef void handler_t(int);
handler_t *signal(int sig, handler_t *handler);   /* identical, readable */

Back to top

Preprocessor directives and predefined macros¶

The preprocessor is a separate language operating on token sequences, executed in translation phase 4 before any C construct is parsed. It has no types, no scope, and no knowledge of the program — which is both why it is portable and why every C project eventually contains a macro nobody wants to touch.

Preprocessing directives. Source: ISO/IEC 9899:2024 §6.10.

Predefined macros other than the feature-test macros listed under Language modes. Source: ISO/IEC 9899:2024 §6.10.10.

/* The two idioms worth memorising. */
#define STR_(x) #x
#define STR(x)  STR_(x)          /* expands x before stringising it */

#define LOG(fmt, ...) \
    fprintf(stderr, "%s:%d: " fmt "\n", __FILE__, __LINE__ __VA_OPT__(,) __VA_ARGS__)

Back to top

Standard headers by revision¶

The standard headers, cumulative. These counts are the second series in the chart on the article’s standard lineage. Source: clause 7 of each revision.

A freestanding implementation must provide only the headers that declare no functions, which in C23 are <float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbit.h>, <stdbool.h>, <stddef.h>, <stdint.h>, <stdnoreturn.h> and <stddef.h>’s type definitions. Everything else — including <stdio.h> and <stdlib.h> — is optional, which is what makes kernel and firmware C conforming rather than a dialect.

Back to top

Standard library map¶

The C standard library is small by modern standards: no containers, no networking, no filesystem traversal, no regular expressions, no string type. Those live in POSIX, in the platform SDK, or in a third-party library, which is why a portable C project’s dependency list starts where this table stops.

The standard library by area, with the traps that most often appear in review. Source: ISO/IEC 9899:2024 clause 7.

Back to top

Conversion specifiers¶

Format strings are unchecked at run time: the variadic call passes what the caller wrote, and a mismatch between the specifier and the argument is undefined behaviour. Compilers do check literal format strings — -Wformat is enabled by -Wall — which is the single best reason never to build a format string dynamically.

Conversion specifiers, then length modifiers. Both tables apply to the whole printf and scanf family; scanf additionally requires a pointer argument and a width for %s. Source: ISO/IEC 9899:2024 §7.23.6.

Back to top

Undefined behaviour: the common cases¶

Annex J.2 of the standard lists undefined behaviour in the low hundreds and is explicitly not exhaustive. The rows below are the ones that appear in real defect reports, each paired with the tool that finds it. The classification and the reasoning behind it are in the article’s treatment of behaviour classes.

The undefined behaviours worth building a pipeline around. None of these is diagnosed reliably by the compiler alone. Source: ISO/IEC 9899:2024 Annex J.2, and the GCC and LLVM sanitizer documentation.

Back to top

Sanitizers and hardening flags¶

Worked transcripts of ThreadSanitizer catching a data race and a lock-order inversion — in programs that print the right answer and never hang — are on the synchronisation page.

Two distinct sets, and confusing them wastes both. Sanitizers are test-time instrumentation that finds undefined behaviour when the test happens to reach it. Hardening flags are release-time mitigations that turn an exploitable defect into a crash. A project that is serious about C uses both, and neither is a substitute for the other.

Sanitizers above the rule, hardening flags below. Availability and spelling differ between GCC, Clang and MSVC; the forms shown are the GCC and Clang spellings. Source: GCC and LLVM documentation and published distribution hardening guidance.

# Two builds, one source tree. The first finds bugs, the second survives them.
cc -std=c23 -O1 -g -fsanitize=address,undefined -fno-omit-frame-pointer -o app-test *.c
cc -std=c23 -O2 -D_FORTIFY_SOURCE=3 -fstack-protector-strong \
   -ftrivial-auto-var-init=zero -fcf-protection=full -pie -Wl,-z,relro,-z,now -o app *.c

Back to top

Sources¶