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 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 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.


------------------------------------------------------------------------------
Last modified on 18 October 2017 by alex@absint.com. Copyright 2017 AbsInt.
------------------------------------------------------------------------------
An HTML version of these release notes is available at
www.absint.com/releasenotes/rulechecker/17.10