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
References
1. 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/IEC
document 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 behaviour
The 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/IEC
9899: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 one
Ideally requirements driven
Bakes in the required qualities of the software
Use it
Collect 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
[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:
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

HIS Conf 2014: An Insight into MISRA-C

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to HIS Conf 2014: An Insight into MISRA-C (20)

More from AdaCore (16)

Recently uploaded (20)

HIS Conf 2014: An Insight into MISRA-C