Main Content

Statically Enforceable AUTOSAR C++14 Rules Supported by Polyspace Bug Finder

The AUTOSAR C++14 standard classifies the rules that are statically enforceable as Automated and Partially Automated. In total, Polyspace® supports 349 out of 349 1 AUTOSAR C++14 coding rules that are enforceable by a static analysis tool.

Automated Rules

According to the AUTOSAR C++14 standard, static analysis detects all violations of the Automated rules. Polyspace Bug Finder supports 327 out of 327 Automated rules that can be enforced by a static analysis tool. The AUTOSAR C++14 standard contains two Automated rules that cannot be enforced by a static analysis tool.

To find the Automated AUTOSAR C++14:

  1. In the Configuration pane of the Polyspace desktop user interface, locate the Coding Standards and Code Metrics node. Select Set checkers by file and click open. Alternatively, use the command polyspace-checkers-selection in the command-line.

  2. In the Checkers Selection window, click New to create a new checkers file. Deselect the coding rules that are already selected.

  3. Select AUTOSAR C++14 in the list of coding standards and defects.

  4. Select the checkbox Decidable.

  5. Save your selection as an XML file.

The content of the XML file lists coding rules that the AUTOSAR C++14 standard classifies as Automated.

Partially Automated Rules

According to the AUTOSAR C++14 standard, static analysis detects only a subset of all possible violation of Partially Automated rules. Polyspace Bug Finder supports 22 out of 22 Partially Automated rules. For details about which error scenarios of a rule Polyspace detects, see the Polyspace Implementation section in the reference page of the rule.

Polyspace supports these Partially Automated rules.

AUTOSAR C++14 RuleDescriptionPolyspace Checker
AUTOSAR C++14 Rule A0-4-4Range, domain and pole errors shall be checked when using math functionsAUTOSAR C++14 Rule A0-4-4
AUTOSAR C++14 Rule A12-0-2Bitwise operations and operations that assume data representation in memory shall not be performed on objectsAUTOSAR C++14 Rule A12-0-2
AUTOSAR C++14 Rule A12-1-5Common class initialization for non-constant members shall be done by a delegating constructorAUTOSAR C++14 Rule A12-1-5
AUTOSAR C++14 Rule A12-8-3Moved-from object shall not be read-accessedAUTOSAR C++14 Rule A12-8-3
AUTOSAR C++14 Rule A14-5-2Class members that are not dependent on template class parameters should be defined in a separate base classAUTOSAR C++14 Rule A14-5-2
AUTOSAR C++14 Rule A15-0-2At least the basic guarantee for exception safety shall be provided for all operations. In addition, each function may offer either the strong guarantee or the nothrow guaranteeAUTOSAR C++14 Rule A15-0-2
AUTOSAR C++14 Rule A15-0-7Exception handling mechanism shall guarantee a deterministic worst-case time execution timeAUTOSAR C++14 Rule A15-0-7
AUTOSAR C++14 Rule A15-1-4If a function exits with an exception, then before a throw, the function shall place all objects/resources that the function constructed in valid states or it shall delete them.AUTOSAR C++14 Rule A15-1-4
AUTOSAR C++14 Rule A15-2-2If a constructor is not noexcept and the constructor cannot finish object initialization, then it shall deallocate the object's resources and it shall throw an exceptionAUTOSAR C++14 Rule A15-2-2
AUTOSAR C++14 Rule A15-3-3Main function and a task main function shall catch at least: base class exceptions from all third-party libraries used, std::exception and all otherwise unhandled exceptionsAUTOSAR C++14 Rule A15-3-3
AUTOSAR C++14 Rule A15-5-2Program shall not be abruptly terminated. In particular, an implicit or explicit invocation of std::abort(), std::quick_exit(), std::_Exit(), std::terminate() shall not be doneAUTOSAR C++14 Rule A15-5-2
AUTOSAR C++14 Rule A18-5-2Non-placement new or delete expressions shall not be usedAUTOSAR C++14 Rule A18-5-2
AUTOSAR C++14 Rule A18-5-5Memory management functions shall ensure the following: (a) deterministic behavior resulting with the existence of worst-case execution time, (b) avoiding memory fragmentation, (c) avoid running out of memory, (d) avoiding mismatched allocations or deallocations, (e) no dependence on non-deterministic calls to kernelAUTOSAR C++14 Rule A18-5-5
AUTOSAR C++14 Rule A18-5-8Objects that do not outlive a function shall have automatic storage durationAUTOSAR C++14 Rule A18-5-8
AUTOSAR C++14 Rule A3-1-5A function definition shall only be placed in a class definition if (1) the function is intended to be inlined (2) it is a member function template (3) it is a member function of a class templateAUTOSAR C++14 Rule A3-1-5
AUTOSAR C++14 Rule A5-1-1Literal values shall not be used apart from type initialization, otherwise symbolic names shall be used insteadAUTOSAR C++14 Rule A5-1-1
AUTOSAR C++14 Rule A5-3-2Null pointers shall not be dereferencedAUTOSAR C++14 Rule A5-3-2
AUTOSAR C++14 Rule A9-3-1Member functions shall not return non-constant "raw" pointers or references to private or protected data owned by the classAUTOSAR C++14 Rule A9-3-1
AUTOSAR C++14 Rule A9-6-1Data types used for interfacing with hardware or conforming to communication protocols shall be trivial, standard-layout and only contain members of types with defined sizesAUTOSAR C++14 Rule A9-6-1
AUTOSAR C++14 Rule M5-0-2Limited dependence should be placed on C++ operator precedence rules in expressionsAUTOSAR C++14 Rule M5-0-2
AUTOSAR C++14 Rule M5-8-1The right hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left hand operandAUTOSAR C++14 Rule M5-8-1
AUTOSAR C++14 Rule M6-2-2Floating-point expressions shall not be directly or indirectly tested for equality or inequalityAUTOSAR C++14 Rule M6-2-2

See Also

Related Topics

1 The AUTOSAR C++14 standard contains 351 statically enforceable rules. The rules A0-4-3 and A1-4-3 are not enforceable by a static analysis tool. These rules might be enforced by your compiler.