[C-safe-secure-studygroup] On MISRA Rule 13.4: The result of an assignment operator should not be used

Fulvio Baccaglini fbaccaglini at perforce.com
Wed Feb 6 14:01:03 GMT 2019


Here is my personal interpretation of Rule 13.4, subject to review.

The applicable C18 paragraphs (equivalent to the C99 references in MISRA C:2012) are:

[C18-J.1-16] Unspecified behavior - "The order in which subexpressions are evaluated and the order in which side effects take place,
except as specified for the function-call () , && , || , ?: , and comma operators".

[C18-J.1-18] Unspecified behavior - "The order in which the operands of an assignment operator are evaluated".

[C18-J.2-35] Undefined behaviour - "A side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object."

Some examples:

~~~~>
int f1 (void)
{
  int x;
  return (x = 2) + (x = 3); // unsequenced side effects
}

void f2 (void)
{
  int v [2] = { 2, 3 };
  int x = 0;
  v [x] = v [x = 1]; // unsequenced side effect and value computation
  return v [0];
}

int x3 = 2;

int g3 (void)
{
  return x3;
}

int f3 (void)
{
  return (x3 += 3) + g3 (); // unspecified behaviour
}
<~~~~

Rule 13.4 relates to Rules 13.2 and 13.3:

* Rule 13.2 - "The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders".

* Rule 13.3 - "A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects than that caused by the increment or decrement operator".

Rule 13.2 would address the general problem of unspecified/undefined behaviours caused by side effects, while Rules 13.3 and 13.4 place further restrictions on the use of the increment/decrement and assignment operators, and they reference behaviours that are already referenced by Rule 13.2.

Note that Rule 13.2 is Required/Undecidable, while Rules 13.3 and 13.4 are Advisory/Decidable. This indicates that their inclusion may help prevent problems that could otherwise skip through the enforcement of Rule 13.2, due to undecidability.

Aside from undefined/unspecified behaviours, the rationales of Rules 13.3 and 13.4 also mentions the issue of code readability.

Other potential problems that Rule 13.4 can prevent are those related with developers incorrectly using '=' instead of '=='.

CERT C includes Rule EXP45-C "Do not perform assignments in selection statements"

Rule EXP45-C also covers a number of other situations besides selection statements, but only where it is deemed that a programming error may typically occur, therefore its scope would be a subset of MISRA Rule 13.4's.

TS 17961 Annex B Undefined Behaviour contains a reference to [C18-J.2-35] but this UB does not appear to be referenced by any rules.

Fulvio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20190206/cd55f1f2/attachment.html>


More information about the C-safe-secure-studygroup mailing list