[C-safe-secure-studygroup] On MISRA C:2012 Rule 13.2

Fulvio Baccaglini fulvio_baccaglini at prqa.com
Fri Mar 9 13:29:15 GMT 2018


Hi,

This is my current personal understanding, to be subject to review.

MISRA C:2012 Rule 13.2 – “The value of an expression and its persistent
side effects shall be the same under all permitted evaluation orders”

Covers the Unspecified Behaviours:

  *

    [C99-J.1-15] ==> [C11-J.1-16] - “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 (6.5).”

  *

    [C99-J.1-16] ==> [C11-J.1-17] - “The order in which the function
    designator, arguments, and subexpressions within the arguments are
    evaluated in a function call (6.5.2.2).”

  *

    [C99-J.1-17] ==> [C11-J.1-18] - “The order of side effects among
    compound literal initialization list expressions (6.5.2.5).”

  *

    [C99-J.1-18] ==> [C11-J.1-19] - “The order in which the operands of
    an assignment operator are evaluated (6.5.16).”

Covers the Undefined Behaviour:

  *

    [C99-J.2-32] - “Between two sequence points, an object is modified
    more than once, or is modified and the prior value is read other
    than to determine the value to be stored (6.5).” ==> [C11-J.2-35] -
    “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 (6.5).”

The Amplification (normative) makes the rule intentionally stricter that
its headline. It is composed of 4 parts, roughly covering cases of:

  *

    C1 - 'simultaneous' modifications of same object

  *

    C2 - 'simultaneous' read and modification of same object

  *

    C3 - 'simultaneous' modifications of same or different volatile objects

  *

    C4 - 'simultaneous' read from same or different volatile objects

C1 & C2 cover both the undefined behaviour (when applied between two
sequence points) and unspecified behaviours (when otherwise applied to a
full expression).

[C11-6.8-4] – Statements and blocks – Semantics - “/A full expression is
an expression that is not part of another expression or of a declarator.
Each of the following is a full expression: an initializer that is not
part of a compound literal; the expression in an expression statement;
the controlling expression of a selection statement (if or switch); the
controlling expression of a while or do statement; each of the
(optional) expressions of a for statement; the (optional) expression in
a return statement. There is a sequence point between the evaluation of
a full expression and the evaluation of the next full expression to be
evaluated./”

I believe that C3 & C4 are intended to capture cases of unspecified
behaviours, when combined with:

  *

    [C11-5.1.2.3-2] Program execution - “/Accessing a volatile object,/
    [etc…] /are all side effects, which are changes in the state of the
    execution environment./”

  *

    [C11-6.7.3-7] Type qualifiers – Semantics - “/An object that has
    volatile-qualified type may be modified in ways unknown to the
    implementation or have other unknown side effects./”

MISRA C:2012 Appendix J Glossary provides the definition of “/persistent
side effect/”. This relates to function calls, and it is based on the
idea that the execution of a function call may involve executing
statements with side effects, but some of these side effects may have
disappeared once the execution returns to the caller.

An interesting interpretation of the meaning of persistent side effect
is also provided in the MISRA Bulletin Board, see query 1478:

https://www.misra.org.uk/forum/viewtopic.php?t=1478

Rule 13.2 is stricter than necessary to prevent undefined and
unspecified behaviours, because its amplification extends from “between
sequence points” to “full expression”.

This strictness makes the rule simpler and the code clearer and easier
to read: requiring side effects to be separated over different
expressions helps making the meaning of those expressions immediately
clear even to less experienced developers, reducing the risk of
misinterpretation.

The rule is classified as undecidable. It should be possible to make the
rule decidable by increasing its strictness, pushing the definition of
persistent side effects further in the direction of BB 1478.

TS 17961 related rules:

  *

    None (?)

CERT C 2016 related rules:

  *

    PRE31-C. Avoid side effects in arguments to unsafe macros

  *

    EXP30-C. Do not depend on the order of evaluation for side effects

  *

    FIO41-C. Do not call getc(), putc(), getwc(), or putwc() with a
    stream argument that has side effects

Fulvio
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20180309/81480c52/attachment.html>


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