[C-safe-secure-studygroup] MISRA rule 13.2 questions

Clive Pygott clivepygott at gmail.com
Fri Mar 23 12:53:54 GMT 2018


Hi

I've been speaking with a couple of member of the MISRA C committee,
including the person that looks after the bulletin board, and whilst
Robert's question will get answered officially eventually (after its been
discussed at a MISRA meeting, hopefully in April) - it will take some time,
and may just say 'Yes, your example does violate this rule'.  So here is my
UNOFFICIAL understanding of the answers to our implied questions:

1)  We are right to assume that an amplification takes precedence over the
headline rule

2)  The reason why the amplification includes 'full expressions' and not
just between sequence points can be illustrated by:

            y  =  x++  +  foo();

where foo includes an assignment to x.

There is a sequence point at the start of the execution of foo()
-  see C11  6.5.2.2 #10.

As I interpret it, the compiler can choose to evaluate  x++  and  foo()  in
either order. If initially  x  has the value  x0, and  foo()  will assign
it  fx(x)  and foo() returns  fr(x), then:

   - if  x++  is evaluated first, the assignment of  x0+1 back to x  has to
   be performed before the execution of foo starts,  so  x finishes up as
   fx(x0+1) and y  ==  x0 +  fr(x0+1)
   - if foo() is evaluated first, x will be assigned fx(x0) before the
   increment is performed,   so  x finishes up as  fx(x0)+1  and  y ==
   fx(x0) +  fr(x0)

For our purposes, I think we can permit the sorts of expressions that
Martin was arguing for by making an exception that  'sub-expressions
separated by  &&  ||  the comma operator .... may be treated as separate
"full expressions" for the purposes of this rule'

3) I asked the question 'does this apply to changes in rounding in floating
point calculations due to the order that sub-expressions are evaluated?'
They're still thinking about that - and also what happens to an integer
expression that may overflow or not depending upon the order of evaluation

Hope this clarifies things

Thanks to Liz Whiting and Chris Tapp for their help

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


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