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

[Robert Seacord]

No, I think we have it on the wiki.  We're just waiting for your
availability to review it.

Hopefully this will be the first thing on the agenda.

rCs

On Wed, Dec 13, 2017 at 11:25 AM, Roberto Bagnara <bagnara at cs.unipr.it>
wrote:

>
> Hi there.
>
> Sorry: I will be traveling again this evening at the time
> of the call.  Looking at the agenda I got the impression
> that my homework for Rule 10.7 was not received (I sent
> it on September 6th, 2017).  Here it is again:
>
>
> MISRA C:2012 Rule 10.7:
> If a composite expression is used as one operand of an operator in
> which the usual arithmetic conversions are performed then the other
> operand shall not have wider essential type.
>
> I assume familiarity with the MISRA C notion of "essential type"
> (see Section 8.10 and Appendix D of MISRA-C:2012).
> I also assume familiarity with the notion of "usual arithmetic
> conversion" (see section 6.3.1.8 of C11).
>
> A "composite operator" is any one of the following:
> binary *, /, %, binary +, binary -, &, |, ^, <<, >>;
> in addition, a conditional operator (?:) is composite if either the second
> or third operand is a composite expression,
> and a compound assignment is, for the purpose of this rule,
> equivalent to an assignment of the result of its corresponding composite
> operator.
> A "composite expression" is any non-constant expression that is
> the direct result of a composite operator, possibly parenthesized.
>
> The rationale of the rule is that C programmers make frequent mistakes
> due to misunderstanding of the language semantics, in which implicit
> conversions play a crucial role.  This specific rule is devised to
> mitigate very common misconceptions regarding the type in which
> arithmetic and bitwise operations are performed.  This is done by
> restricting implicit conversions on composite expressions, thereby
> imposing that sequences of arithmetic/bitwise operations within an
> expression are conducted in exactly the same essential type.
>
> I routinely see programmers (even seasoned programmers) making
> dangerous mistakes that can be prevented by imposing this rule (and
> other related rules).  I thus recommend its inclusion tout court.
>
> --
>      Prof. Roberto Bagnara
>
> Applied Formal Methods Laboratory - University of Parma, Italy
> mailto:bagnara at cs.unipr.it
>                               BUGSENG srl - http://bugseng.com
>                               mailto:roberto.bagnara at bugseng.com
>
>
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-
> safe-secure-studygroup
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20171213/a3a59d6c/attachment.html>