/sota-c-cpp

name: sota-c-cpp
description: >-
  State-of-the-art C and C++ engineering rules that Claude
  applies when writing or auditing C/C++. Covers modern idioms (RAII, value
  semantics, smart pointers, C++23), memory safety (lifetimes, bounds,
  sanitizers, hardening flags), undefined behavior, security (SEI CERT C/C++,
  MISRA, integer/buffer/format-string, injection), concurrency (C/C++ memory
  model, atomics, data races), build/tooling/CI (CMake, clang-tidy, cppcheck,
  ASan/UBSan/TSan, vcpkg/Conan, supply chain), and performance. Trigger keywords
  - C, C++, RAII, smart pointer, unique_ptr, shared_ptr, undefined
  behavior, UB, buffer overflow, use-after-free, sanitizer, ASan,
  UBSan, TSan, valgrind, CMake, clang-tidy, cppcheck, MISRA, CERT
  C, memory safety, std::thread, atomics, std::move. Use for BOTH building
  C/C++ libraries/systems and reviewing or auditing them. Owns firmware's LANGUAGE
  layer; does NOT own its SYSTEMS layer — ISRs, DMA coherency, MMIO, RTOS
  scheduling, priority inversion, WCET, linker scripts — unowned library-wide.

SOTA C & C++ (2026)

Expert-level rules for producing and auditing production C and C++. C and C++ are *memory-unsafe by default*: the compiler will not stop you from reading freed memory, overrunning a buffer, or invoking undefined behavior (UB) that the optimizer then weaponizes. These rules exist to claw back the safety the language doesn't give you — through RAII, the type system, sanitizers, hardened build flags, and disciplined review. Baseline: C++23 (ISO/IEC 14882:2024) and C17/C23; flag where a control needs a newer toolchain. C++26 is feature-complete (DIS ballot 2026) — contracts, reflection, erroneous behavior for uninitialized reads, and a standardized hardened standard library; the last is usable today via libc++/libstdc++ hardening flags ([`rules/02`](rules/02-memory-safety.md)). Every rule states the *why*; every rules file ends with an audit checklist of grep/clang-tidy/ sanitizer patterns.

Purpose

Two consumers, one source of truth:

• **BUILD mode** — generating new C/C++: follow the rules as defaults, not

suggestions. Prefer C++ with RAII over raw C idioms unless the target is C. Deviate only with a comment justifying it.

• **AUDIT mode** — reviewing existing C/C++: hunt violations using the audit

checklists, classify by severity, report in the finding format below. Memory- safety and UB findings are presumed exploitable until proven otherwise.

**What this skill covers about embedded work, and what it does not.** It carries the safety-critical *coding* standards — MISRA C:2025 / C++:2023 and SEI CERT ([`rules/04`](rules/04-security.md)), freestanding builds with exceptions disabled ([`rules/01`](rules/01-idioms.md) §7), banned APIs and hardened build flags — so a firmware codebase gets real coverage of the language layer. The device's boot chain, debug-port lock, over-the-air update integrity and anti-rollback, and decommissioning live in [`sota-security-compliance` rules/05](../sota-security-compliance/rules/05-iec-62443-ot-ics.md) §6 and [rules/04](../sota-security-compliance/rules/04-eu-cyber-resilience-act.md) §2. It does **not** cover the systems layer that makes embedded work its own discipline: interrupt service routines and reentrancy, DMA buffer coherency, memory-mapped I/O and `volatile` semantics against a peripheral, RTOS task scheduling and priority inversion, WCET and timing analysis, or linker scripts and startup code. No skill in this library owns those today. Say so when the task reaches them rather than generalising from the desktop rules — guidance that sounds authoritative outside its scope is the failure [`sota-skill-security`](../sota-skill-security/SKILL.md) exists to catch.

BUILD mode

1. Before writing, read the rules files relevant to the task (see index). A parser handling untrusted bytes needs `02`, `03`, `04`; a threaded service needs `05`. 2. Apply the **top-10 non-negotiables** (below) unconditionally. 3. New projects: CMake (≥3.20) with `-Wall -Wextra -Wpedantic` (`-Werror` in CI, not in distributed sources), the [OpenSSF hardening flags](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html) ([`rules/04`](rules/04-security.md)), a debug build wired to ASan+UBSan, clang-tidy + clang-format configs, and CI running all of it from day one ([`rules/06`](rules/06-build-tooling-ci.md)). 4. Prefer the standard library and RAII types over hand-rolled allocation/ownership. Every `new`/`malloc`/`fopen`/`mutex.lock()` should be owned by a destructor (`unique_ptr`, container, `lock_guard`), not a manual matching call you can forget on an early return or exception. 5. Treat warnings as errors. A clean `-Wall -Wextra` build is the floor, not the goal — also run a static analyzer and the sanitizers ([`rules/06`](rules/06-build-tooling-ci.md)). 6. When you must use a sharp tool (raw pointer arithmetic, `reinterpret_cast`, `unsafe` C interop, manual lifetime), leave a `// NOTE(sota):` comment explaining the invariant you're upholding so auditors don't flag it blind.

AUDIT mode

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

Work through each relevant rules file's audit checklist against the target. Run the listed grep/clang-tidy/sanitizer commands; confirm each hit manually (greps are recall-oriented). Where feasible, build with `-fsanitize=address, undefined` and run the test suite — a sanitizer abort is ground truth.

Severity conventions

| Severity | Meaning | Examples | |---|---|---| | **CRITICAL** | Exploitable memory corruption or guaranteed UB on reachable input | Heap/stack buffer overflow on attacker data, use-after-free, double-free, OOB write, format-string with user-controlled fmt, `system()`