519
Total rules shipped
Native PhantomYerra pack
519 AUTOSAR C++14 rules - exceeds the published standard via PhantomYerra extensions. Full rule pack covering AUTOSAR's A-class (analyzable), M-class (MISRA-derived), and Rh-class (human-only) categories. Adaptive Platform-ready. Layered on top of the YerraCPP 4,574-rule core scanner.
AUTOSAR C++14 is the de-facto standard for safety-critical automotive C++ in projects targeting AUTOSAR's Classic and Adaptive platforms. PhantomYerra ships 519 rules total - every published AUTOSAR rule (the AUTOSAR 18-10 release lists 397 rules) plus 122 PhantomYerra extensions covering modern toolchain edge cases that have emerged since the standard's last update.
AUTOSAR partitions rules by what a tool can decide automatically. A-rules are fully automatable. M-rules are inherited from MISRA C++:2008 and re-stated for AUTOSAR. Rh-rules ("human only") cannot be decided by a tool and require code review - PhantomYerra emits Rh findings as advisories so reviewers see them.
| Class | Definition | PhantomYerra count | Behavior |
|---|---|---|---|
| A-class (Analyzable) | Fully automatable - a static-analysis tool can decide compliance deterministically. | ~270 | Hard fire |
| M-class (MISRA-derived) | Inherited from MISRA C++:2008. Restated for AUTOSAR semantics. | ~155 | Hard fire |
| Rh-class (Human-review) | Not decidable by a tool - emitted as advisory for reviewer attention. | ~94 | Soft fire / advisory |
Counts are approximate distributions; the exact split per pack revision is documented in resources/compliance/AUTOSAR_Cpp14.json inside the PhantomYerra distribution. PhantomYerra's A-class detectors run with cross-tool corroboration against the CodeQL cpp query pack for additional signal.
Every AUTOSAR rule is identified by a triple - for example A8-4-7: A-class, Section 8, Subsection 4, Rule 7. M-class rules are similarly numbered but prefixed M. The PhantomYerra rule pack uses the published IDs verbatim, so reports cite the canonical clause directly.
| Section | Topic | Sample rule ID | What it enforces |
|---|---|---|---|
| Section 2 | Lexical conventions | A2-3-1 | Only ISO 10646 characters in source. No non-ASCII identifiers. |
| Section 3 | Basic concepts | A3-1-1 | Declarations that share a name must be the same kind. No mix of variable and type with the same name. |
| Section 5 | Expressions | A5-2-2 | No C-style casts. Use static_cast / dynamic_cast / const_cast / reinterpret_cast explicitly. |
| Section 6 | Statements | A6-5-1 | A for-loop shall contain a single loop-counter which shall not have floating-point type. |
| Section 7 | Declarations | A7-1-1 | Constexpr or const specifier shall be used for objects whose values do not change after initialisation. |
| Section 8 | Declarators | A8-4-7 | "In" parameters of a function shall be passed by const reference if they are large. |
| Section 9 | Classes | A9-3-1 | Member functions shall not return non-const "raw" pointers or references to private/protected data. |
| Section 12 | Special member functions | A12-1-1 | Constructors shall explicitly initialise all virtual base classes, all direct non-virtual base classes, and all non-static data members. |
| Section 14 | Templates | A14-5-2 | Class members that are not dependent on template parameters should be defined in a separate base class. |
| Section 15 | Exception handling | A15-1-2 | An exception object shall not be a pointer. |
| Section 18 | Library introduction | A18-9-1 | The std::bind function shall not be used. |
Representative emissions across an A-class, an M-class, and an Rh-class rule - to show what a finding looks like in a real PhantomYerra report.
C-style casts conflate four very different operations - static_cast, dynamic_cast, const_cast, reinterpret_cast - into a single ambiguous syntax. In safety-critical C++ that ambiguity is unacceptable: the maintainer cannot read the code and know whether a runtime check happens, whether constness is being discarded, or whether a reinterpret is on the wire.
YerraSAST rule fired: CPP-AUTOSAR-A5-2-2-c-style-cast · cross-checked against the cpp/c-style-cast CodeQL query.
double f = 3.14; int n = (int)f; // AUTOSAR A5-2-2 violation - use static_cast<int>(f)
Inherited from MISRA C++:2008 Rule 5-0-4. Implicit conversion between signed and unsigned types can silently change the value being represented - and on safety-critical systems silent change is a bug class banned at compile time.
YerraSAST rule fired: CPP-AUTOSAR-M5-0-4-signedness-conversion.
unsigned int u = 100u; int s = u; // M5-0-4 violation - implicit signed/unsigned
Implicit initialisation in C++ is dangerous when one member's default constructor reads another member's value. AUTOSAR A12-1-1 mandates an explicit member-initialiser-list entry for every member; PhantomYerra checks all constructors in the project and reports missing initialisers per finding.
YerraSAST rule fired: CPP-AUTOSAR-A12-1-1-uninit-member · cross-checked against cpp/uninitialized-field.
class Thermostat { int setpoint_; double current_; public: Thermostat() {} // A12-1-1 - setpoint_ and current_ left uninit };
AUTOSAR Adaptive Platform - introduced in AUTOSAR 17-10 - is the POSIX-based, dynamically-linked, service-oriented runtime for ADAS and autonomous-driving ECUs. It runs on modern multicore SoCs with full C++17/20 toolchains, which means the AUTOSAR C++14 ruleset gets stretched. PhantomYerra ships extension rules that close the gap: modern parallel-execution constructs, dynamic-memory patterns, and ARA (AUTOSAR Run-time for Adaptive Applications) API usage rules.
| Adaptive concern | PhantomYerra extension rule | What it catches |
|---|---|---|
| Parallel STL | CPP-PY-ADAPTIVE-001 | Use of std::execution::par_unseq on iterators with side-effects - UB on most implementations. |
| Dynamic memory | CPP-PY-ADAPTIVE-014 | Use of std::malloc/std::free in a service requiring AUTOSAR memory pool. |
| ARA::COM | CPP-PY-ADAPTIVE-022 | Missing error-handling on a ProxyHandle service discovery. |
| ARA::EXEC | CPP-PY-ADAPTIVE-031 | Missing ReportState call between kStarting and kRunning transitions. |
| ARA::PER | CPP-PY-ADAPTIVE-045 | Persistent data accessed without explicit transaction boundary. |
AUTOSAR C++14 alone does not deliver functional-safety compliance - it pairs with ISO 26262 to do so. PhantomYerra emits findings tagged with both AUTOSAR clause and the ISO 26262 Part-6 control objective (where applicable). This dual tagging lets ASIL-D projects produce a single audit-ready report covering both standards.
| AUTOSAR rule | ISO 26262 Part 6 objective | ASIL relevance |
|---|---|---|
| A5-2-2 (no C-style cast) | § 8.4.5 - type system | ASIL B+ |
| A7-1-1 (const-correctness) | § 5.4.7 - defensive programming | ASIL A+ |
| A15-1-2 (no pointer in exception) | § 5.4.7 - defensive programming | ASIL C+ |
| A12-1-1 (init all members) | § 9.4 - design verification | ASIL B+ |
| M5-0-4 (signedness conversion) | § 8.4.5 - robustness | ASIL C+ |
Coverity does not publicly disclose its AUTOSAR C++14 rule count. PhantomYerra ships 519 rules total - 397 of the published AUTOSAR rules plus 122 PhantomYerra extensions for Adaptive Platform / modern toolchain concerns the published standard does not address.
Where PhantomYerra exceeds: (1) Adaptive Platform native rules - Coverity has no documented ARA::COM / ARA::EXEC / ARA::PER coverage; (2) ISO 26262 dual-tagging - every AUTOSAR finding is also tagged with the applicable ISO 26262 Part-6 objective so a single scan satisfies both audits; (3) cross-tool corroboration with CodeQL on every A-class rule; (4) AI false-positive scoring on Rh-class (human-review) emissions to help reviewers prioritise; (5) perpetual licence pricing.