AUTOSAR C++14 Compliance

Cuttlefish can check its generated C++ against a curated subset of the AUTOSAR C++14 coding standard. The feature is opt-in, off by default, and writes a machine-readable deviation registry next to your emitted code.

In Short

Add --autosar=strict to your build command.
Cuttlefish checks its C++ output against ~50 AUTOSAR C++14 rules.
If a violation is found, the build tells you the file, line, and rule.
Violations that can’t be eliminated are recorded as documented deviations in a sidecar file.

You write TypeScript as usual. The compliance check runs after the C++ is generated but before it’s written to disk.

Enabling Compliance

cuttlefish build --autosar=off      # default — no enforcement
cuttlefish build --autosar=warn     # log violations + write sidecar, build succeeds
cuttlefish build --autosar=strict   # abort on required violations
cuttlefish build --autosar          # bare flag = strict

Add --autosar-arxml to also produce an ARXML-format deviation file for tooling like Artop or DaVinci:

cuttlefish build --autosar=warn --autosar-arxml

What the modes do

Mode	Self-check	Sidecar written	Build result
`off` (default)	none	no	unchanged
`warn`	logged as warnings	yes	succeeds
`strict`	required violations become errors	yes	aborts on any required unrecorded violation

Reading the output

Diagnostics

When a violation is found, the diagnostic points at both your TypeScript and the generated C++:

warning [AUTOSAR_M5-0-7] (66,1): AUTOSAR M5-0-7 unrecorded-violation at main.ts:66 (emitted at main.cpp:109): int64_t deadline = esp_timer_get_time() + static_cast<int64_t>(ms) * 1000;

The format gives you both locations so you can fix the TypeScript or understand why the C++ triggered the rule.

Sidecar registry

A <name>.autosar-deviations.json file is written next to the emitted C++. Each entry traces the deviation to both the TypeScript source and the C++ location:

{
  "schemaVersion": "1.0.0",
  "standard": "AUTOSAR C++14",
  "tool": "cuttlefish",
  "emittedArtifact": "main.cpp",
  "deviations": [
    {
      "ruleId": "M3-2-1",
      "line": 42,
      "justification": "Adafruit HAL requires a static-storage global instance.",
      "reviewStatus": "auto-generated",
      "source": {
        "tsFile": "src/hardware/display.ts",
        "tsLine": 12,
        "kind": "hal-instance"
      },
      "cpp": {
        "file": "main.cpp",
        "line": 42
      }
    }
  ]
}

The source field points at the TypeScript that caused the deviation. The cpp field points at the exact line in the emitted C++. The reviewStatus starts at "auto-generated" and would be promoted to "accepted" after human review as part of your safety workflow.

ARXML output

Add --autosar-arxml to produce a <name>.autosar-deviations.arxml file alongside the JSON. This is the AUTOSAR-standard XML format consumed by tooling like Artop and DaVinci.

What gets checked

The ~50-rule subset covers rules that can be evaluated from the generated C++ text. The main categories:

Type safety — C-style casts banned (static_cast required), no implicit narrowing, fixed-width integers (int32_t not int under --autosar).

Memory — no malloc/calloc/realloc (use new (std::nothrow)), scoped enums (enum class), using aliases instead of typedef.

Control flow — no recursion, no goto, switch must have default, [[fallthrough]] required.

Source organization — final on leaf classes, override on virtual methods, #pragma once for header guards, <cstring> instead of <string.h>.

Rules requiring cross-file analysis (dependency-ordered static initialization across translation units) or runtime semantics (atomic copy behavior) are out of scope.

Deviations

When a violation is genuinely unavoidable — a library API requires a global instance, a platform toolchain mandates a C header, a canvas buffer needs heap allocation — Cuttlefish records a deviation with a justification instead of aborting the build.

The deviation appears as an inline comment in the C++ (recognized by Helix QAC, Coverity, and Axivion deviation parsers):

Adafruit_ST7796S __tc_display(...);  // AUTOSAR Deviation M3-2-1: Adafruit HAL requires static storage.

And in the sidecar registry with full traceability to both TypeScript and C++.

What it doesn’t do

The compliance check covers rules that can be evaluated from a single file’s generated C++ text. Several categories are out of scope:

No cross-file analysis. Rules that require seeing multiple translation units together — like dependency-ordered static initialization (M3-2-2) or cross-file dead-code tracking (M0-1-1) — can’t be evaluated at emit time. These rules are excluded from the subset.

No runtime analysis. Rules whose semantics depend on program behavior — like detecting unsafe atomic copies (M5-2-9 beyond the text-level check) — are excluded.

No throw analysis. The noexcept rule (A15-0-2) requires proving a function can’t throw, which needs whole-function call-graph analysis. Cuttlefish records this as an advisory deviation on every function rather than attempting the analysis. A future version may add real noexcept annotations where provable.

No certification. Cuttlefish emits the deviation artifacts (JSON, ARXML, inline comments). It does not certify code, run external checkers, or integrate with Helix QAC, Coverity, or Axivion beyond producing files those tools can consume.

No review workflow. Each deviation’s reviewStatus starts at "auto-generated". Promoting it to "accepted" — the human sign-off step that safety standards require — is your process, not Cuttlefish’s.

No full AUTOSAR rule set. The subset is ~50 rules out of the ~300+ in the full AUTOSAR C++14 standard. Rules outside the subset are not checked, not even as advisory deviations. If a rule you need isn’t covered, it can be added to the curated rule table.

Verification

Check your own project by building it with the checker on. A clean build, with no unrecorded violations reported, means it passes:

npx @typecad/cuttlefish build --autosar=strict

On This Page