MISRA C Development Process

1
MISRA C Development Process

• Chris Tapp

2
Team Members

• All members of the MISRA-C Working Group are
  unpaid volunteers.
• Core technical members
• Richard Corden, Programming Research
• Mike Hennell, LDRA
• Derek Jones, Knowledge Software
• Clive Pygott, QinetiQ
• Chris Tapp, Keylevel Consultants (Chairman)
• MIRA provide admin and IT services for MISRA.
• David Ward provides significant organisational
  assistance.

3
MISRA C Process

• Identification of Issues
• QinetiQ Vulnerabilities Report
• Evaluation of Existing Material
• Other Coding Standards
• MISRA-C
• JSF
• Medical Systems
• Transportation
• Tool Vendors (real world experience).
• Other Publications
• Scott Meyers
• Stephen Dewhurst
• Etc.

4
MISRA C Process

• New Rule Formulation
• Needed where existing material fails to cover
  identified issues or where better enforcement is
  required.
• Broken into features that are championed by a
  sponsor (i.e. Clive / Exceptions).
• Can be difficult to decide where to add the rules
  if the issue is common to more than one section.

5
MISRA C Process

• Peer Review
• Rules are reviewed by the organisations involved
  in the development process as soon as they become
  reasonably stable.
• A Draft Document will be put out for review to a
  wider set of reviewers. Please feel free to take
  part!
• All feedback will be analysed and any major
  changes put out for further review.

6
MISRA C Process

• The final document will be released when
• Peer review is complete.
• The Working Group are satisfied with the quality
  of the document content.
• The MISRA Steering Group give approval for
  release.

7
QinetiQ Vulnerabilities Report

• Unlike ISO/IEC 98991990 (C), ISO/IEC 148822003
  (C) does not have a section listing all
  undefined, unspecified and implementation defined
  behaviour.
• QinetiQ Report identifies all such issues within
  ISO/IEC 148822003.
• Report also considers issues raised by other
  authors.
• One aim is to cover all the (tool-enforceable)
  issues identified by this report.

8
MISRA C Rules

• Many of the issues with C are shared with C, so
  MISRA-C has also been used as a source of rules.
• Some MISRA-C rules can be used as is.
• Some MISRA-C rules require minor changes.
• Some MISRA-C rules require significant re-work
  but are still useful.
• Some MISRA-C rules are not applicable to C.

9
MISRA C Document

• Subset will target ISO/IEC 148822003 C.
• Layout will be similar to MISRA-C and will be
  targeted at programmers.
• Rules will be grouped so as to follow ISO/IEC
  14882 section numbers.
• Cross Reference tables will be provided, allowing
  tracing to/from the QinetiQ Vulnerabilities
  Report.
• Document planned to be released as
• Paper Copy
• Corporate Licence / pdf
• Personal pdf

10
MISRA C Document

• Rule Structure
• Rule Number and category (Required)
• Headline Text
• Issue and Existing Material References
• Explanation of the issue(s) and rule
  justification.
• Examples of non-conforming and, where
  appropriate, conforming code.
• Expected deviations (if appropriate and may
  include none!).

11
To Do

• Categorise rules
• Mandatory for rules that must not be deviated.
• Required for rules that require formal
  deviation.
• Advisory / Guideline for rules that cannot be
  easily enforced.
• Example Suite (Future Project)
• Examples showing compliant and non-compliant
  examples of the rules to aid in tool selection.
• NOT a Conformance Suite.