[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