C ecosystem and systems architecture

Scope and deep-review findings¶

This is an architecture review, not a ranking of compilers, kernels, RTOSes, or libraries. The graph selects components that reveal distinct interfaces and proof obligations. A real system will omit most of them, add vendor-specific pieces, and pin exact revisions; its job is to preserve the boundaries made visible here.

Back to top

History: from Unix tool to systems substrate¶

C emerged between 1969 and 1973 because the early Unix team needed a language above assembly that still fit a small machine and exposed its useful operations. BCPL’s and B’s word-oriented economy survived, while C acquired types and a compiler capable of expressing most of an operating system. The 1973 Unix rewrite was the decisive architectural demonstration: machine-dependent assembly could be concentrated at narrow edges rather than spread across the kernel. Source: The Development of the C Language.

K&R C spread through Unix ports before a formal standard fixed the language and library. ANSI C89 and ISO C90 converted practice into a portable contract. Later standards accumulated facilities without erasing installed dialects: C99 reshaped numeric and declaration practice; C11 introduced the language memory model and atomics; C17 consolidated corrections; C23 became the fifth ISO edition in October 2024. Linux, embedded vendors, and safety programs still select their own baselines because a standard’s publication and a deployed toolchain’s contract are different clocks.

All 13 milestones in data/c-ecosystem.json. A milestone records a change in the language or its architectural role, not a usage ranking.

Back to top

One syntax, several contracts¶

The ISO standard defines the meaning of a conforming C program in an abstract machine and intentionally does not specify how it becomes an executable or is invoked. Every serious architecture therefore needs a contract stack: language edition, extension policy, compiler and flags, target triple, ABI, runtime or reset environment, library profile, link layout, concurrency model, and assurance rules.

The contracts overlap in an implementation, but they answer different questions. Treating one as a proxy for another creates portability and assurance gaps. Sources: ISO/IEC 9899:2024 — Programming languages — C; POSIX.1-2024, The Open Group Base Specifications Issue 8; System V Application Binary Interface AMD64 Architecture Processor Supplement; MISRA C:2025 — Guidelines for the use of the C language in critical systems.

C23 is current, but “uses C23” is incomplete. Linux documents GNU C11; CMSIS describes a portable processor interface plus device-specific startup; a freestanding firmware may link only selected libc facilities; an airborne component may be constrained by project plans, tool qualification, and object-code evidence. The standard is the semantic floor, not the deployed architecture.

Back to top

Full ecosystem context map¶

The visual projects every component marked as part of the architectural spine. Lines are directional relationships; the relationship register preserves their type, meaning, and evidence. Secondary implementations and domain alternatives remain in the lossless register so the map can stay readable without pretending that C has one official distribution.

The central path is source and headers through preprocessing, compilation, assembly, object files, linking, and loading or reset. The upper contracts constrain that path. The lower systems reuse it differently: Linux owns its libc-free privileged runtime; an RTOS owns scheduling but delegates board startup; ROS 2 exposes C APIs as language-neutral middleware seams; FFmpeg uses portable C as its reference and dispatch surface around assembly and device-specific acceleration.

Back to top

Source-to-silicon toolchain¶

Translation stages and the evidence each hands to the next. Reproducibility requires the complete command line, generated inputs, target data, linker script, startup objects, library choice, and tool versions—not only the compiler version.

make, CMake, and Meson occupy different levels. Make executes a file dependency graph. CMake and Meson model targets and usage requirements, then generate a native graph. pkg-config reports installed compile/link flags but does not fetch dependencies. Conan and vcpkg can acquire and build packages, but neither creates a universal C package identity: target ABI, compiler runtime, feature flags, patches, and link mode remain part of the resolved artifact.

Back to top

The C and assembly boundary¶

C does not standardize registers, stack frames, symbol spellings, object files, instruction selection, or inline assembly. Those belong to the compiler and target ABI. On x86-64, AArch64, and RISC-V the details differ, but the architecture question is constant: what state crosses the function boundary, what may be destroyed, how are values classified, where is the stack, and how are machine-visible side effects communicated to the compiler?

Assembly integration choices. Prefer the highest-level mechanism that still expresses the required instruction and side effects; that preserves more compiler analysis and reduces handwritten ABI surface.

An inline asm volatile is not automatically a compiler memory barrier and is not automatically correct. Inputs, early-clobber outputs, condition codes, memory effects, register overlap, and control flow must match the template. Out-of-line routines move that contract into the platform ABI, which is often clearer for a substantial function and lets C, assembly, and tests evolve independently. Preprocessed .S files can share configuration and symbolic constants with C, but that also imports macro-state risk into assembly.

The robust pattern visible in kernels and FFmpeg is reference + dispatch + conformance test: retain a readable scalar C implementation, select an ISA-specific implementation only after capability checks, and compare optimized outputs and preserved state against the reference. Assembly then becomes a replaceable implementation of a small contract, not an invisible second language inside arbitrary expressions.

Back to top

Linux kernel architecture¶

At this snapshot kernel.org lists Linux 7.2.3 as stable and 7.3-rc1 as mainline. Those numbers date the ecosystem, but architecture lives in longer-lived boundaries. The kernel documentation still defines the C language as GNU C11, supports GCC and Clang/LLVM toolchains, and makes architecture code and build configuration first-class parts of the system. Sources: The Linux Kernel Archives; Programming Language; Building Linux with Clang/LLVM.

A kernel C review checklist organized by architecture rather than syntax. Every driver also needs its subsystem-specific locking, power-management, DMA, firmware, and teardown rules.

Kconfig and kbuild¶

Kconfig defines a product family; .config selects one member. kbuild combines top-level rules, an arch/$(SRCARCH)/Makefile, common scripts, and per-directory obj-y/obj-m declarations. It creates thin built-in.a archives, links the resident vmlinux, builds loadable .ko modules, and hands the result to architecture-specific boot-image processing. C source, preprocessed assembly, generated offsets, linker scripts, host tools, BTF/debug data, and post-link checks all participate; “compile the .c files” is not a kernel build model.

Contexts, subsystems, and drivers¶

Core code supplies shared abstractions; architecture code implements entry, exceptions, atomic primitives, barriers, memory translation, context switching, and alternatives; drivers bind device behavior to bus and subsystem contracts. A loadable module changes delivery, not privilege: it executes in the kernel address space. eBPF is different again—restricted instructions enter through a verifier and interpreter/JIT path with explicit helper and hook contracts.

The important UML-like relationship is not “driver inherits kernel.” It is a set of protocols over time: probe establishes resources, publication exposes the device, concurrent operations borrow state, quiesce stops new work, teardown waits for in-flight users, and removal releases resources in reverse dependency order. Lock order, RCU grace periods, reference ownership, interrupt disable state, work cancellation, and DMA completion are the real edges.

Back to top

Embedded and real-time architecture¶

In firmware, “runtime” is assembled rather than inherited. Reset code, a linker script, device startup, interrupt vectors, C library retargeting, board support, an optional RTOS, and the application together create the environment that a hosted C implementation normally supplies. CMSIS standardizes much of the Arm-facing vocabulary but intentionally leaves concrete devices and peripherals to vendor packs and board code.

Representative embedded execution models. Selection follows the product timing, isolation, connectivity, safety, update, footprint, and hardware-support requirements—not feature count.

Memory, interrupts, and devices¶

The linker script owns the physical image: vector table, executable text, read-only data, initialized data, zeroed storage, retained/no-init regions, stacks, heaps, shared memory, and sometimes overlays or tightly coupled memory. Startup code must realize that layout before ordinary C assumptions hold. An ISR and main/task context are concurrent even on one core; volatile describes accesses to volatile-qualified objects but is neither a lock nor a complete hardware ordering primitive. DMA adds another agent, with ownership, cache maintenance, alignment, and completion rules that belong in the component contract.

Real-time design¶

Analyze response time across interrupt latency, release jitter, priority, worst-case execution, blocking, preemption, cache and bus interference, message queues, driver work, and actuator deadlines. Ban or phase-limit allocation when fragmentation or failure cannot be bounded. Size each stack from measurement plus justified margin. Give overload an intentional outcome—drop, coalesce, degrade, shed, reset, or enter a safe state—rather than letting a full queue or missed watchdog choose one accidentally.

Back to top

Military, avionics, and high assurance¶

C’s defense and avionics use is less about the language being intrinsically safe than about the surrounding investment: long-supported processors, deterministic RTOSes, board support, analyzers, traceability systems, qualified or controlled toolchains, test equipment, interface standards, and staff able to review object-level behavior. The architecture must preserve that evidence without freezing every component behind one vendor.

Public standards and guidance relevant to critical C systems. Applicability is contractual and domain-specific; this table is a system-design map, not compliance or certification advice.

Partitioning and open interfaces¶

FACE separates portable components from transport, operating-system, I/O, and platform services. MOSA makes modularity and open, verifiable interfaces a life-cycle acquisition strategy. For C, the interface still needs more than a header: binary versioning, data representation, timing, resource ceilings, initialization order, concurrency, failure containment, health reporting, update compatibility, security classification, and ownership of verification artifacts.

Source is not the final artifact¶

Optimization, undefined behavior, implementation-defined choices, generated code, link selection, libraries, startup, and post-link rewriting can separate reviewed source from executing bytes. Critical workflows therefore identify the exact compiler/linker configuration and released image, qualify or verify tools when their failure could remove required assurance, and close traceability through target integration. Whether disassembly or object-code verification is required is a project assessment—not something MISRA compliance decides.

Back to top

Robotics and deterministic middleware¶

ROS 2’s internal architecture makes C a deliberate language-neutral seam. rcl implements shared client behavior and graph concepts; rmw is the minimal interface to replaceable middleware; generated type support bridges message definitions to serialization. Language clients such as C++, Python, and rclc build above that C core rather than each binding directly to one DDS vendor.

The executor is an architectural scheduler. A middleware can retain messages and enforce delivery QoS, but it cannot bound an application callback or resolve priority inversion in shared resources. rclc’s executor exists precisely to give embedded C systems more control over callback order and trigger conditions. A hard real-time sense-plan-act chain should have explicit release conditions, bounded message memory, analyzed callback times, and isolated best-effort logging, visualization, discovery, and remote-service paths.

C is also the FFI layer under many non-C nodes and hardware SDKs. Treat that as a protocol: generated message structs need initialization/finalization; allocators must not cross ownership domains accidentally; QoS and type compatibility must be versioned; cancellation and shutdown must outlive callbacks; handles need clear thread affinity; and zero-copy loans require lifetime rules stronger than a raw pointer expresses.

Back to top

Drones and autonomous vehicles¶

PX4 makes the core decomposition explicit: middleware supplies hardware integration and communication; the flight stack supplies estimation and control. uORB is an asynchronous publish/subscribe bus inside the system; NuttX is the primary flight-controller RTOS; Linux commonly hosts richer companion software. ArduPilot uses a different codebase and hardware-abstraction structure but exposes the same architectural pressures: bounded control loops, portable device support, simulation, persistent parameters, and external vehicle protocols.

Autonomous-vehicle system boundaries. The same architecture also applies to rovers, boats, and other robots; airworthiness, regulation, and operational constraints depend on the actual system and use.

Message passing improves replaceability but does not create safety by itself. Every control input needs a time basis, validity window, source/authority, coordinate frame, unit, range, and loss behavior. Queueing a stale setpoint preserves delivery while violating control intent. A companion link should have an explicit state machine: absent, discovered, healthy, degraded, rejected, and recovered, with the flight controller retaining the authority needed for its defined safe response.

Simulation should preserve build options, message schemas, scheduler assumptions, and parameter sets, then be complemented by software-in-the-loop, hardware-in-the-loop, bench, and controlled physical tests. Fault injection is most useful at named boundaries—sensor timeout, timestamp jump, queue overflow, estimator reset, actuator saturation, storage corruption, link loss—not as an undirected collection of random failures.

Back to top

FFmpeg and multimedia dataflow¶

FFmpeg 9.0.1 was the current stable release on this snapshot, with major-versioned libavutil 61, libavcodec/libavformat/libavdevice 63, libavfilter 12, libswscale 10, and libswresample 7. The command-line tools orchestrate those libraries; they are not a monolithic codec engine. Source: Download FFmpeg.

The main FFmpeg library decomposition. Public APIs and major library versions are the integration surface; internal structures and optimized functions are not equivalent compatibility promises.

Assembly, dispatch, and hardware frames¶

Codec and transform hot paths often dispatch from C to x86, Arm, AArch64, or other ISA-specific functions. FFmpeg’s checkasm framework compares optimized implementations with reference behavior and can check calling-convention preservation. That is the right relationship: C defines the callable surface and scalar oracle; the build selects ISA objects; runtime detection selects a supported path; tests establish equivalence.

Hardware acceleration adds a second memory domain. Decode may produce a device frame that filters or encoders can reuse without download, but format negotiation, device/context lifetime, synchronization, pool exhaustion, fallback, and error recovery become graph properties. “Zero copy” means an avoided transfer along one path, not the absence of ownership or synchronization.

Untrusted media and temporal correctness¶

Demuxers and decoders parse adversarial lengths, offsets, tables, recursion, entropy-coded state, and container relationships. Checked arithmetic, allocation ceilings, fuzzing, sanitizers, regression vectors, and minimal enabled surfaces complement review. Temporal correctness is separate: preserve explicit time bases, distinguish decode and presentation order, rescale deliberately, and define discontinuity, drift, buffering, and backpressure behavior at every live boundary.

Back to top

Use-case architecture register¶

The same language participates in very different systems. The table makes the deployment contract and design boundary primary; the component list is representative. It should help an architecture review ask “which C? in which protection domain? under which scheduler and ABI?” before discussing local syntax.

9 domain projections derived from c-ecosystem.json. Components recur because compiler, ABI, debugging, and assurance surfaces cut across application categories.

Back to top

Memory safety and trust boundaries¶

Current CISA/FBI guidance calls developing new product lines in memory-safe languages the preferred direction and asks existing products to prioritize memory-safety roadmaps. NSA/CISA guidance also recognizes incremental adoption and interoperability rather than assuming every installed C system can be rewritten at once. For a C architecture, that creates a concrete obligation: identify high-risk components, shrink unsafe surfaces, place memory-safe components where practical, and make the remaining C case measurable and time-bounded. Sources: Product Security Bad Practices; Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development.

Trust boundaries across the C life cycle. Compiler hardening, sanitizers, static analysis, fuzzing, MPU/MMU isolation, capability hardware, process separation, coding rules, and review are complementary controls.

A useful memory-safety roadmap classifies by exposure and authority: network/media parsers, privileged code, cryptographic and identity components, update paths, and cross-domain brokers normally deserve priority. At each seam, use length-carrying APIs, checked arithmetic, explicit ownership, opaque state, narrow privileges, bounded resource use, process or hardware isolation where available, and differential tests between old and new paths.

Back to top

Architecture decision guide¶

11 review prompts stored in the ecosystem graph. They are starting positions, not universal prescriptions; a measured constraint or applicable assurance process can change the answer.

A complete C architecture decision record names at least: language/dialect and extensions; target ABIs and endianness/data models; compiler, linker, startup and libc; build and dependency provenance; address spaces and privilege; buffer ownership; concurrency contexts; allocation policy; error/fault/reset behavior; assembly and generated-code seams; supported hardware; analysis/test matrix; update compatibility; and the exact released binary identity. If one of those is “whatever the toolchain does,” that is still a decision—just an unstable one.

Back to top

Component and relationship register¶

This is the lossless text form of the visual map. Stable IDs are graph keys; names are labels. The build rejects duplicate IDs, dangling relationship endpoints, unknown layers/statuses/relation kinds, self-edges, uncited assertions, unused sources, invalid snapshot dates, and non-chronological milestones before rendering.

Components¶

All 50 components in data/c-ecosystem.json. Status distinguishes standards, tools, implementations, project code, domain projects, and external boundaries; it is not a maturity score.

Relationships¶

All 69 typed relationships in data/c-ecosystem.json. Every endpoint resolves to one component above, and every edge carries upstream evidence.

Back to top

Current direction and durable role¶

C23 is a real modernization of the language, and WG14 has already moved into C2y work, but the most important current ecosystem change happens outside syntax: stronger pressure to prevent memory-safety defects, mix memory-safe languages into existing systems, isolate parsers and privileged services, preserve exact build provenance, and treat binary and hardware contracts as reviewable architecture.

C will remain difficult to displace where it is itself the interface: firmware startup, platform ABIs, libc, kernel internals, device SDKs, language runtimes, codecs, and stable foreign-function surfaces. That durable role does not imply that every adjacent component should also be C. A healthy modern system tends to make the C core narrower, more explicit, more heavily checked, and easier to replace or wrap.

The deepest common pattern across Linux, RTOS firmware, robotics, drones, and FFmpeg is a narrow portable contract over replaceable machine-specific implementations. It succeeds when the boundary carries enough truth: ABI and layout, ownership and lifetime, time and ordering, resource ceilings, error states, capability discovery, fallback, and verification. C’s future is strongest where those contracts are visible—and weakest where a raw pointer or undocumented macro is expected to carry them by convention.

Back to top

Sources¶

Language, platform, standards-body, regulator, government, and upstream project sources were checked for this 2026-09-03 snapshot. Version numbers are included only where they date a claim; project documentation remains the authority after the snapshot.

1. ISO/IEC 9899:2024 — Programming languages — C, ISO.
2. C project status and milestones, ISO/IEC JTC 1/SC 22/WG14.
3. The Development of the C Language, Bell Labs / Dennis M. Ritchie.
4. POSIX.1-2024, The Open Group Base Specifications Issue 8, The Open Group / IEEE.
5. System V Application Binary Interface AMD64 Architecture Processor Supplement, x86-64 psABI project.
6. Procedure Call Standard for the Arm 64-bit Architecture, Arm.
7. RISC-V ELF psABI Document, RISC-V International.
8. MISRA C:2025 — Guidelines for the use of the C language in critical systems, The MISRA Consortium.
9. SEI CERT C Coding Standard, Carnegie Mellon Software Engineering Institute.
10. FACE Technical Standard and corresponding documents, The Open Group FACE Consortium.
11. Modular Open Systems Approach, U.S. Department of Defense, OUSD(R&E).
12. MIL-STD-882E Change 1 — System Safety, U.S. Department of Defense ASSIST.
13. AC 20-115D — Airborne Software Development Assurance Using ED-12() and DO-178(), U.S. Federal Aviation Administration.
14. GNU Make Manual, GNU Project.
15. CMake Documentation, Kitware.
16. The Meson Build System, Meson project.
17. Ninja Manual, Ninja project.
18. Guide to pkg-config, freedesktop.org.
19. Conan 2 documentation, Conan project.
20. vcpkg documentation, Microsoft.
21. The C Preprocessor, GNU Project.
22. Using the GNU Compiler Collection, GNU Project.
23. Extended Asm — Assembler Instructions with C Expression Operands, GNU Project.
24. Clang documentation, LLVM Project.
25. C language reference, Microsoft.
26. Using as — GNU Assembler, GNU Project.
27. LD — GNU Linker, GNU Project.
28. Linker Scripts, GNU Project.
29. System V ABI — Generic ABI, Xinuos.
30. PE Format, Microsoft.
31. The GNU C Library Reference Manual, GNU Project.
32. About musl, musl libc project.
33. The Newlib Homepage, Newlib project.
34. Picolibc C library for embedded systems, Picolibc project.
35. Debugging with GDB, GNU Project.
36. LLDB documentation, LLVM Project.
37. AddressSanitizer, LLVM Project.
38. UndefinedBehaviorSanitizer, LLVM Project.
39. Clang Static Analyzer, LLVM Project.
40. The Linux Kernel Archives, Linux Kernel Organization.
41. Programming Language, Linux kernel documentation.
42. Building Linux with Clang/LLVM, Linux kernel documentation.
43. Linux Kernel Makefiles, Linux kernel documentation.
44. Kconfig Language, Linux kernel documentation.
45. Core API Documentation, Linux kernel documentation.
46. The Linux driver implementer's API guide, Linux kernel documentation.
47. Building External Modules, Linux kernel documentation.
48. BPF Documentation, Linux kernel documentation.
49. Assembler Annotations, Linux kernel documentation.
50. System Emulation Introduction, QEMU Project.
51. CMSIS Introduction, Arm.
52. Using CMSIS in Embedded Applications, Arm.
53. FreeRTOS kernel fundamentals, Amazon Web Services / FreeRTOS.
54. Zephyr Project Documentation, Zephyr Project.
55. Devicetree access from C/C++, Zephyr Project.
56. RTEMS Documentation, RTEMS Project.
57. Apache NuttX Documentation, Apache Software Foundation.
58. Internal ROS 2 interfaces, Open Robotics.
59. ROS 2 Executors, Open Robotics.
60. rclc — ROS client library in C, Open Robotics / micro-ROS.
61. PX4 Architectural Overview, PX4 / Dronecode Foundation.
62. uORB Messaging, PX4 / Dronecode Foundation.
63. Learning ArduPilot — Introduction, ArduPilot Project.
64. MAVLink Developer Guide, MAVLink Project.
65. Download FFmpeg, FFmpeg Project.
66. FFmpeg Documentation, FFmpeg Project.
67. FFmpeg library modules, FFmpeg Project.
68. Libavformat Documentation, FFmpeg Project.
69. FFmpeg Developer Documentation, FFmpeg Project.
70. checkasm — for all your assembly checking needs, FFmpeg Project.
71. FFmpeg Hardware Acceleration, FFmpeg Project.
72. Product Security Bad Practices, CISA and FBI.
73. Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development, NSA and CISA.