RuleChecker release 17.10

Re-categorization of MISRA rules

RuleChecker now supports re-categorizing MISRA rules, e.g. using DAX:

<rulechecks>
  <categories>
    <M2012.7.1>mandatory</M2012.7.1>
  </categories>
</rulechecks>

This re-categorization is then reported by the analyzer as

Rules:
M2012.7.1 (full: octal-constant) as mandatory

while violations of the rule are reported as

ALARM (R): check octal-constant failed (violates M2012.7.1-mandatory) at ...

Flagging automatically-generated code

RuleChecker configurations now have a flag indicating whether the files therein contain hand-written or generated code. Depending on this flag,

• messages about rule violations refer either to the “MISRA C” or the “MISRA AC AGC” category, and
• values in either the “MISRA C category” or the “MISRA AC AGC category” column can be modified to permit re-categorization (according to the rules established by MISRA).

By default the tool assumes hand-written code. In DAX, the configurations for automatically generated code can be specified with the new attribute agc:

<rulechecks name="xxx" agc="yes">

Options

• The option allow-signed-constant-with-unsigned now also suppresses alarms about the operands of <<, >> and ~.
• The option allow-boolean-constants now also suppresses alarms about equality checks (==, !=) between the essentially Boolean values and 0 or 1.

Checks

• float-comparison now also covers indirect (in)equality tests of the form a - b < c && b - a < c.
• evaluation-order has been split in two:
  • evaluation-order now only triggers an alarm if the semantics of an expression depends on the order of evaluation of its sub-expressions. It does not consider multiple reads or writes of volatile variables.
  • multiple-volatile-accesses triggers an alarm for an expression if there are at least two reads or two writes of a volatile object in that expression and if the check evaluation-order has not triggered an alarm for it.
• expression-order has been replaced by two checks:
  • the new evaluation-order check as described above, that triggers an alarm if the semantics of an expression depends on the order of evaluation of its sub-expressions
  • the check evaluation-order-initializer that triggers an alarm if the semantics of an initializer list depends on the order of evaluation of its elements.
• Double slashes within //-style comments are no longer treated as a violation of the check sline-comment. This modification affects MISRA-C:2012 rule 3.1 and CERT rule MSC.4.

Qualification Support Kits

• 226 new test cases have been added to the RuleChecker QSK.
• Under Windows, the maximum path length limitation (as specified by Microsoft) is now checked every time a test case is loaded.

Other changes

• Alarms about rule violations now contain the essential types involved, when applicable. For example, for the code

  if (2) {}

  the analyzer now reports

  ... expected essentially Boolean but is essentially signed at ...
  ALARM (R): check boolean-control failed (violates M2012.14.4-required) at ...

• Improved precision for pointer dereferences in the side effect analysis. This yields fewer false alarms about violations of the checks evaluation-order and expression-order and fewer false notifications about ambiguities due to side effects in expressions or initializers.

Bug fixes

• Fixed coverage reported under /* Active rule checks */ for rules fully covered with Astrée but only partially covered by the standalone RuleChecker.
• Fixed crashes that could occur on very large compilation units.
• Fixed evaluation of regular expressions for identifier name checks which in rare cases were only matched against prefixes instead of the whole identifier.

MISRA-C:2004

• Improved checks for rule 9.1, 14.1, 12.8, and 13.7 when running in standalone mode, i.e. without the Astrée analyzer.
• Astrée-intrinsic functions for modelling concurrent execution, such as __astree_create_process(), are no longer considered to violate the check statement-sideeffect used in rule 14.2.
• Alarms about violations of the check definition-duplicate for rule 8.9 now show the locations of both involved definitions.
• The new check parameter-match-type checks for function calls not matching the prototype of the called expression (cf. ISO/IEC 9899:1999, §6.5.2.2p2). It is used for rule 1.1 and 16.6.
• Improved the checks identifier-hidden for rule 5.2 and max-locals for rule 1.1 with respect to compound expressions (GCC extension), removing false alarms about violations of these rules.
• RuleChecker now also reports violations of the checks evaluation-order and expression-order whenever an object is modified multiple times between two sequence points. This affects rule 12.2.
for expressions that involve function designators.
• The check shift-with-constant for rule 12.8 now additionally warns about too-wide shifts at compound assignments using <<= or >>=.
• Fixed a false alarm at the last statement in a compound expression (GCC extension) for rule 4.2.
• Fixed checks of rule 11.1 and 16.9
• The check include-syntax for rule 19.3 now additionally warns about dangling tokens following the header-name token in the same line.

MISRA-C:2012

• Added support for rule 18.1.
• Improved checks for rule 2.1, 12.2, and 14.3 when running in standalone mode, i.e. without the Astrée analyzer.
• Alarms about violations of the check definition-duplicate for rule 8.6 now show the locations of both involved definitions.
• Enum types are now classified as anonymous or named when checking coding rules. This affects rule 10.1, 10.2, 10.3, 10.4, and 10.5.
• Added the check implicit-function-declaration to rule 1.1.
• The new check parameter-match-type checks for function calls not matching the prototype of the called expression (cf. ISO/IEC 9899:1999, §6.5.2.2p2). It is used for rule 1.1.
• Fixed a false alarm at the last statement in a compound expression (GCC extension) for rule 4.2.
• Improved the check distinct-identifier-hidden to remove false alarms about violations of rule 5.3.
• The check identifier-unique-tag for rule 5.7 no longer raises false alarms about forward declared tags.
• RuleChecker now also reports violations of the checks evaluation-order and expression-order whenever e an object is modified multiple times between two sequence points. This affects rule 13.2.
• Macro parameters as operand of the # operator no longer cause false alarms about violations of rule 20.7 by triggering the check macro-parameter-unparenthesized-expression.
• RuleChecker now also warns about violations of rule 10.3 for initializers in which the initialized (sub-)object is of floating-point type.
• The check essential-shift-width-constant for rule 12.2 now additionally warns about too-wide shifts:
  • if the left-hand operand is of essentially character type
  • at compound assignments using <<= or >>=
• The check include-syntax for rule 20.3 now additionally warns about dangling tokens following the header-name token in the same line.
• Fixed false alarm for rule 8.3 in case of forward-declared struct tags.
• Fixed checks of rule 11.1 for expressions that involve function designators.
• Double slashes within //-style comments are no longer treated as a violation of the check sline-comment, which affects rule 3.1.

CWE

RuleChecker now supports the CWE (Common Weakness Enumeration) guidelines.

SEI CERT C

Double slashes within //-style comments are no longer treated as a violation of the check sline-comment, which affects rule MSC.4.

Diagnostics

• New rules:
  • A.1.5 warns about function calls not matching the prototype of the called expression (cf. ISO/IEC 9899:1999, §6.5.2.2p2) using the new check parameter-match-type.
  • A.1.6 warns about _Static_assert declarations that cannot be proven to hold.
  • A.2.2: Assembler code shall be avoided.
  • A.2.3: Absolute addresses shall be avoided.
  • A.2.4: Only strictly conforming constant expressions shall be used.
  • A.2.5: Enums shall not be forward-declared.
  • A.2.6: Lvalue casts shall be avoided.
  • A.2.7: Non-standard keywords shall not be used.
  • A.2.8: Pointer attributes shall be avoided.
  • A.2.9: Statement expressions shall be avoided.
• Rule A.3.2 now warns about the use of multi-character char constants.

Style rules

Many additional rules have been added that cover the naming of all C identifiers. These rules are nested by identifier namespace, scope or similar.

• For each kind of identifier, there are configurable rules for length and spelling, using regular expressions. If available, the regular expressions can use the patterns %Filename%, %Folder###%, %bitsize% and %Type% to refer to the name of the current file, the ###-th parent folder of the current file, the bitsize of the entity’s type or the type itself.
• The string used for %Type% can be configured via the option type-abbreviations.
• The part of the filename which is used for %Filename% can be configured via the option file-name-modifier.

Customer-specific rules

• Rule X.A.3.7 now supports UTF-8 and ISO-8859-1 encoded files.
• Improved the check identifier-hidden for rule X.A.5.14 with respect to compound expressions (GCC extension), removing false alarms about violations of this rule.
• RuleChecker now also reports violations of the checks evaluation-order and expression-order whenever an object is modified multiple times between two sequence points. This affects the customer-specific rule X.A.5.34.
• Fixed checks for rule X.A.5.57 for expressions that involve function designators.
• The check shift-with-constant for rule X.A.5.39 now also warns about too-wide shifts at compound assignments using <<= or >>=.

Code metrics

Fixed the display of metric values in messages about violation of thresholds for cyclomatic complexity and nesting of control structures. The messages now show the exact value computed by the analyzer.