his conf 2014: an insight into misra-c

1

An Insight into MISRA C 2012

© 2014 Rolls‐Royce PLC

This talk is based on MISRA C 2012. However, the rationale behind MISRA C and the principles for its use apply to all three versions; 1998, 2004, and 2012.Nothing in this talk and presentation slide pack (with accompanying notes) should be taken as adding to, or altering the meaning of, any of the MISRA C publications. E&OE. Polite feedback is of course welcomed.

2



3



Note: There are contradictions in the arguments cited for and against the use of C; nobody said the arguments were rational in their choice of focus. For example, structured programming is good, but imperative (machine action oriented) programming bad; except that structured programming relies on imperative programming!

4



See http://en.wikipedia.org/wiki/History_of_programming_languages

References1. Kernighan, Brian W.; Ritchie, Dennis M. (February 1978). The C Programming Language

(1st ed.). Englewood Cliffs, NJ: Prentice Hall. ISBN 0‐13‐110163‐3.2. Page 3 in reference [1]

C is an old language (circa 1972) that evolved and was then standardised by ANSI in 1989 (C89) and adopted by ISO and IEC in 1990 as ISO/IEC 9899 (C90). Corrections to the ISO/IECdocument where made in 1995. The standard was then revised and published as ISO9899:1999 (C99) and again in 2011 (C11). With each of the revisions to the standard, some archaic aspect of the language was deprecated and subsequently removed. New language and library features have of course been added.

5



C’s design was driven by the needs of system programming for which it became synonymous with the UNIX operating system and system utilities. This in part goes a long way towards understanding C as being a hybrid of a generic machine‐code assembly language (2GL) and a structured programming language (3GL). This conflation of programming concerns gives cause for concern from those that would like to see strict adherence to structured programming techniques. However, back when C was conceived it was strictly the programmers problem to ensure their C program was correct because the compilers did not have sufficient working memory to perform anything but the programmes translation from source code to object code. To counter this problem a compilation like tool was created to perform automated checks on the source code and since this was seen as being a task akin to picking the fluff from fabric, the tool was called “lint”.Further reading:• Wikipedia article http://en.wikipedia.org/wiki/C_(programming_language)• Denis Ritchie article “The Development of the C Language” http://cm.bell‐

labs.com/cm/cs/who/dmr/chist.html• “Safer C: Developing Software for High‐Integrity and Safety‐Critical Systems” Les Hatton,

ISBN‐10: 0077076400, ISBN‐13: 978‐0077076405

6



Some additional issues that are often cited as being problematic with C are:• The Preprocessor• Integer promotion rules for the small integer types are not intuitive• Integer type sizes are dictated by the target architecture; the standard only sets out the

minimum requirements for each type• Implicit type conversion• Enumerate types are integers and are therefore not type distinct (fixed in C++)• Single name space (fixed in C++)• Standard heap memory manager is far to simplistic for practical long term use• And many more…

Note that Rule 12.1 in MISRA C 2012 has a precedence table with 17 entries consisting of one entry for identifiers and literals, and 16 further entries for the operators.

7



References:[1]: The Development of the C Language, Dennis M. Ritchie, April 1993, http://cm.bell‐labs.com/cm/cs/who/dmr/chist.html (accessed 26 August 2014)

8



9



References:[1] Annex G in ISO/IEC 9899:1990[2] Annex J in ISO/IEC 9899:1999

Define a “safe” subset from the ISO/IEC9899 standard:• Prohibit the use of language features that have:• Undefined behaviour• Critical Unspecified behaviour• Implementation chosen behaviourThe safe subset has Standard defined program semantics• Consistently and predictably understood by all ISO C Standard conforming tools

10



Note: “goto” is generally read as a synonym for unstructured programming, and unstructured programmes can be hard to verify correctness, let alone maintain. Hence “unstructured programming” ≡ “bad programming”, therefore “goto” ≡ “bad programming”.However, there are perfectly legitimate uses of “goto” as part of a structured programming approach to the use of C. For example, where avoiding its use leads to more convoluted code that is potentially harder to understand (i.e. read) than if a “goto” had been used. Examples of this are jumping out of nested loops, dealing with exceptions, etc.This is often referred to as a “tamed goto”.

11



MISRA C 2004 provides coverage for ISO/IEC 9899:1990 with TC1 (1995) (C90).MISRA C 2012 provides coverage for ISO/IEC 9899:1990 with TC1 (1995) (C90) and ISO/IEC9899:1999 (C99)

It says very little about:• Source code style

That’s your business, but have one and be consistent• The software development process

Have oneIdeally requirements drivenBakes in the required qualities of the software

Use itCollect evidence to prove it

12



MISRA C 2012 has 159 guidelines. Divided into two classifications• Directives (16)• Rules (143)With three categories of compliance:• Mandatory (10)• Required (110)• Advisory (39)Rules are guidelines that have a complete description of what is required. Directives are guidelines that establish a principal, but one for which a complete description of what is required is not possible. In that sense, rules are precise about their C coding standard requirements and directives are abstract and require interpretation for each project and situation.The three categories of compliance set out a baseline expectation for claiming compliance to MISRA C. All mandatory guidelines must be satisfied. All required guidelines must be satisfied, except for those with explicit formal deviation statements. The advisory guidelines are recommendations that may (more freely) be deviated from.

13



116 of the guidelines are considered to be decidable. That’s 73% of the 159 guidelines or 81% of the 143 rules, since the directives are implicitly undecidable.

Rule decidability is discussed in section 6.5 in MISRA C 2012. It also provides in Appendix B a list of the guidelines with their “analysis” attributes, which include decidability.

14



Note: MISRA C 2012 formally recognises Project and Specific deviations. The “architectural category” of deviation is drawn out, in this presentation, as a specific subset of the Project deviation category to emphasis the point that different coding standard rules can be defined for each aspect of the software systems architecture as required.

15



Note: MISRA C 2012 states in section 6.2.2 “An organization or project may choose to treat any required guidelines as if they were mandatory”, and in section 6.2.3 “An organization or project may choose to treat any advisory guideline as if they were mandatory or required”.

See MISRA C 2012 section 5.4 for the formal deviation process requirements.

16



The default position is that all language features considered “harmful” are prohibited, e.g.

• goto (Rule 15.1)• union (Rule 19.2)Such features can be “enabled” by a deviation to the guideline that prohibits their direct use.However, finer grained guidelines typically provide constraint on the use of such language features, e.g.

• Rule 15.1 The goto statement should not be used (advisory)• Rule 15.2 The goto statement shall jump to a label declared later in the same function

(required)

• Rule 15.3 Any label referenced by a goto statement shall be declared in the same block or in any block enclosing the goto statement (required)

• Rule 15.4 “There should be no more than one break or goto statement used to terminate any iteration statement” (advisory)

• Rule 9.1 “The value of an object with automatic storage duration shall not be read before it has been set” (mandatory) – which prevents the use of goto from skipping over initialiser statements.

17



18



19



20



21



The page image in this slide, and on the following slides, is from reference [1].In order to use MISRA C, it is necessary to develop and document:[2]

• A compliance matrix, showing how compliance with each MISRA C guideline will be checked;

• A deviation process by which justifiable non‐compliances can be authorized and recorded;• The demonstration that the project’s C code is MISRA C compliant subject to the project’s

approved deviations;• The Project’s engineering process meets the process requirements detailed in sections 3, 4,

& 5 and summarised in Appendix F (see next slide);• People involved in the development of MISRA C compliant C source code are competent to

do so.Note that compliance can only be claimed for the software project.[3]

References:[1]: MISRA C Guidelines for the use of the C language in critical systems, March 2013, MIRA Limited, ISBN 978‐906400‐10‐1 (paperback)[2]: Section §5.2.1 in [1][3]: Section §5.5 in [1]

22



Verification that C code complies with the guidelines precisely and absolutely is fraught with the difficulty of proving that the implementation of such checks are robust. Informal and semi‐formal techniques will be used and the project must address the risk of approving C code that could be shown to be non‐compliant. A typical strategy is to use more than one technique (and tool) for each guideline with the assumption that flawed checks in one do not overlap with the flaws in the other. This layered set of verification “defences” (often referred to as the “Swiss Cheese” model) should have as many layers of checking as required to satisfy the project’s risk/integrity profile. Thus, projects at the lower end of the risk/integrity scale may decide that a single static analysis tool in conjunction with the compiler’s checks, source code inspection, and dynamic testing are sufficient. Whereas a project at the higher end of the risk/integrity scale may opt for multiple static analysis tools from different vendors with different pedigrees, combined with a sophisticated dynamic test process that leverages multiple compiler technologies for multiple test platforms.The next slide illustrates a compliance matrix for a project that has determined that its risk/integrity profile are best served by two independent compilers and static analysis tools.

23



Note: Table extracted from reference [2]

References[1]: MISRA C Guidelines for the use of the C language in critical systems, March 2013, MIRALimited, ISBN 978‐906400‐10‐1 (paperback)[2]: Section §5.3 in [1]

24



This is essentially process definition and process execution evidence, with the spot light over those areas that concern MISRA C; e.g. procedures and evidence for the assessment of development tool fitness for purpose. See next slide for the summary check list.

25



Note: Page extracted from reference [1]

References:[1]: MISRA C Guidelines for the use of the C language in critical systems, March 2013, MIRALimited, ISBN 978‐906400‐10‐1 (paperback)

26



Required for compliance, but no explicit guidance is provided by MISRA C. However, a clear test of competency for critical systems software development with MISRA C 2012 is the knowledge that MISRA C is more than just about the adherence to its guidelines! (I.e. the process objectives set out in sections 3, 4, & 5.)

27



28



A copy of MISRA C 2012 can be purchased from www.misra.org.uk in both PDF and paperback formats.

29



30



31

