© Programming Research
www.programmingresearch.com
An Introduction to MISRA C:2012
Paul Burden
Webinar will start shortly
© Programming Research
2
Welcome
• A warm welcome to all our visitors
• The Webinar will last for approx 50 minutes
• We will take 10 minutes of questions at the end
© Programming Research
3
GoToWebinar Attendee Interface
© Programming Research
4
Paul Burden
• Technical Consultant working for
PRQA
• Expert in coding standards
enforcement
• Product Manager for PRQA’s
leading static analysis tool QA·C
• Prominent member of the MISRA C
Working Group since its formation
more than 10 years ago.
© Programming Research
5
Agenda
1. An Introduction to MISRA C
2. The Changes in MISRA C:2012
3. Guideline Classification
4. MISRA C Compliance
© Programming Research
6
MISRA C
MISRA C:1998
• Derived from PRQA standards developed for Ford and Rover
• Developed in UK for automotive applications
MISRA C:2004
• Amended and extended
• Supplemented with an Exemplar suite
MISRA C:2012
• A committee of 10 representing many years of experience
• 4 years of effort
• Released 18th March 2013
• A further step forward …
© Programming Research
7
Coding standard adoption
VDC Research
White Paper* April 2011:
“Re-evaluation of Development and Testing Practices April 2011”
Available at:
www.programmingresearch.com/whitepapers
Data obtained from 600 respondents
in Embedded and Enterprise/IT
software and systems development.
0.0%
10.0%
20.0%
30.0%
40.0%
Coding Standard Adoption
by % of Respondents
© Programming Research
8
MISRA C
• Automotive
• Aerospace
• Defence
• Medical
• Nuclear power
• Railways
• Consumer electronics
• Process control
• etc.
MISRA C is now the most widely used coding
standard for the C language - worldwide
© Programming Research
9
Agenda
1. An Introduction to MISRA C
2. The Changes in MISRA C:2012
3. Guideline Classification
4. MISRA C Compliance
© Programming Research
10
The Changes in MISRA C:2012
MISRA C:2012 compared to MISRA C:2004
• It's bigger
– a few more rules (159 instead of 142 )
– and the content is better
• Many guidelines are unchanged
– they may be reworded and better specified
– guideline/rule numbering has changed
• Legacy code may not be compliant
– there are new requirements – not many
– but some restrictions have been removed
© Programming Research
11
C language support
ISO:C90
• Well supported by compilers and tools
• The dangers are well understood
• Limitations – e.g. absence of Boolean type
ISO:C99
• More features, e.g. _Bool and inline functions
• More dangers, e.g. additional undefined behaviour
• Most compilers do not support all features of C99
ISO:C11
• Still relatively new
• Very limited tool support
MISRA C:1998
MISRA C:2004
MISRA C:2012
MISRA C:2012
© Programming Research
12
Guideline specification
An expanded
explanation of the
requirement
Why the guideline
is necessary
More extensive
code examples
Headline text
clarification
Exceptions
© Programming Research
13
Terminology
MISRA terminology has changed
These terms were
loosely defined and
have been replaced
The new terms are fully
defined and used to
describe expressions
of any arithmetic type
MISRA C:2004 MISRA C:2012
underlying type essential type
complex expression composite expression
effectively Boolean essentially Boolean
© Programming Research
14
Agenda
1. An Introduction to MISRA C
2. The Changes in MISRA C:2012
3. Guideline Classification
4. MISRA C Compliance
© Programming Research
15
Guideline classification
Category
• Advisory
• Required
• Mandatory Decidability
• Decidable
• Undecidable
Language
• C90
• C99
• C90, C99
Guideline Type
• Directive
• Rule Analysis Scope
• Single Translation Unit
• System
© Programming Research
16
Rules and Directives
Rules
– Have well defined requirements
– Are statically enforceable (subject to certain limitations)
Directives
– May be loosely defined – allowing alternative interpretations
– May address "process" or "documentation" requirements
There are now 2 types of guideline:
© Programming Research
17
Rules and Directives - examples
Rules
Rule 8.5 An external object or function shall be declared once in
one and only one file
Rule 11.3 A cast shall not be performed between a pointer to object
type and a different pointer to object type
Dir 3.1 All code shall be traceable to documented requirements
Dir 4.3 Assembly language shall be encapsulated and isolated
Directives
© Programming Research
18
Guideline categories
• Advisory guidelines
– These are recommendations
– Non-compliance is permitted at the user's discretion
– Non-compliance should be documented
– Formal deviations are not required
• Required guidelines
– Non-compliance must be supported by a formal "deviation"
• Mandatory guidelines
– Must always be obeyed
– Compliance is always required
Mandatory guidelines
were not a feature of
previous versions of
MISRA C
There are now 3 guideline categories:
© Programming Research
19
Rule decidability
A rule is decidable if it is always possible, in any program,
for a tool to determine whether code is compliant. Otherwise
the rule is undecidable
Rules are either "decidable" or "undecidable"
Rule 12.4 Evaluation of constant expressions should not lead to
unsigned integer wrap-around
Decidable …
Undecidable …
Rule 13.5 The right hand operand of a logical && or || operator shall not
contain persistent side effects
© Programming Research
20
Analysis scope
There are 2 types of "analysis scope"
Single Translation Unit Rules
System Rules
Rule 8.2 Function types shall be in prototype form with named parameters
Rule 16.4 Every switch statement shall have a default label
Rule 8.7 Functions and objects should not be defined with external
linkage if they are referenced in only one translation unit
Rule 13.5 The right hand operand of a logical && or || operator shall not
contain persistent side efects
© Programming Research
21
Guideline Classification Summary
CLASSIFICATION SUMMARY
DIRECTIVES
(16)
RULES
(143)
CATEGORY Advisory 7 32
Required 9 101
Mandatory 0 10
LANGUAGE C90 0 2
C99 0 11
C90 or C99 16 130
DECIDABILITY Decidable - 117
Undecidable - 26
ANALYSIS SCOPE Single Translation Unit - 104
System - 39
Some rules are now classified
as "mandatory"
Some rules are only relevant
for a specific language version
Some rules cannot be statically
enforced with certainty
Rules that can be enforced
within a single translation unit
are decidable
© Programming Research
22
Agenda
1. An Introduction to MISRA C
2. The Changes in MISRA C:2012
3. Guideline Classification
4. MISRA C Compliance
© Programming Research
23
MISRA C Compliance
• Enforceability
• Decidability
• Deviations
What do we mean by "MISRA Compliant Code" ?
© Programming Research
24
Enforceability
143
16
"The vision for the third edition of MISRA C is therefore to:
…
Increase the number of guidelines that can be processed by static analysis tools"
…
MISRA C:2012 Chapter 1 – The Vision
Rules - can be
automatically
enforced
Directives – tools can
sometimes assist with
enforcement
© Programming Research
25
Enforceability
Independent Research performed by
TERA-Labs, a new research division of
the Karel de Grote university college in
Antwerp, Belgium.
• Test code was written for 11 key rules
in MISRA C:2004 - selected by a panel
of industrial partners
• The test code was analysed using a
number of analysis tools claiming to
enforce compliancy with MISRA C
• Two tool attributes were examined
– Effectiveness in identifying rule violations
– Incidence of false positive messages
No False
Positives
Many False
Positives
All
violations
reported
No
violations
reported
GOOD
BAD
"The ability to detect the maximum number of violations possible, while minimizing the number of
false positive messages, is therefore an important factor in choosing a tool."
MISRA C:2012 Chapter 3.2 Analysis Tools
© Programming Research
26
Tool Enforcement
Tool
XYZ
The author of the TERA-Labs
report observed:
“On paper all the selected tools
claimed to provide comprehensive
MISRA C compliance checking
– but the reality was different.”
www.programmingresearch.com/resources/white-papers
© Programming Research
27
MISRA C Compliance
• Enforceability
• Decidability
• Deviations
© Programming Research
28
Decidability
"In order to use MISRA C, it is necessary to develop and document …
• A compliance matrix, showing how compliance with each MISRA C guideline will be checked"
MISRA C:2012 Chapter 5.2.1 – Process activities required by MISRA C
"Where a guideline cannot be completely checked by a tool, then a manual review will be required."
MISRA C:2012 Chapter 5.3 – Compliance
117
26
16
MISRA C:2012 Guidelines
Decidable Rules
Undecidable Rules
Directives
© Programming Research
29
MISRA C Compliance
• Enforceability
• Decidability
• Deviations
What do we mean by "MISRA Compliant Code" ?
© Programming Research
30
Deviations
"In order to use MISRA C, it is necessary to develop and document …
• A deviation process by which justifiable non-compliances can be authorized and recorded "
MISRA C:2012 Chapter 5.2.1 – Process activities required by MISRA C
" It is important that such deviations are properly recorded and authorized."
MISRA C:2012 Chapter 5.4 – Deviation procedure
Deviations are often necessary …
… but the process can also be abused
MISRA C ADC: Approved deviation compliance for MISRA C:2004
ISBN 978-906400-09-5 (PDF), February 2013.
Freely downloadable from www.misra.org.uk
© Programming Research
31
Deviation Management
• Deviation support
• Documentation
• Collaborative code review
• Baselining
© Programming Research
32
Agenda
In Conclusion …
© Programming Research
33
In conclusion …
• Effective, accurate, automatic enforcement
MISRA C
2012
QA
C
• Disciplined compliance and deviation management
• Enforceable, decidable, well-specified coding rules
© Programming Research
34
Do you have any questions?
© Programming Research
35
MISRA C:2012 microsite
www.programmingresearch.com/mc3
• Download our MISRA C:2012 whitepaper
• Share our 1-page MISRA C:2012 summary
• Watch our videos about coding standards
• Access the MISRA webstore
© Programming Research
36
Do you have any questions?
© Programming Research
37
Thank you
Thank you for tuning in and giving an hour of your valuable time !
We will email the video link of this presentation and a summary of
the Q&A shortly.
Email us to ask any questions or for any follow-up points of interest.
Paul Burden
paul_burden@programmingresearch.com
Please don’t forget to fill in our short survey to tell us how we did !

An Introduction to MISRA C:2012

  • 1.
    © Programming Research www.programmingresearch.com AnIntroduction to MISRA C:2012 Paul Burden Webinar will start shortly
  • 2.
    © Programming Research 2 Welcome •A warm welcome to all our visitors • The Webinar will last for approx 50 minutes • We will take 10 minutes of questions at the end
  • 3.
  • 4.
    © Programming Research 4 PaulBurden • Technical Consultant working for PRQA • Expert in coding standards enforcement • Product Manager for PRQA’s leading static analysis tool QA·C • Prominent member of the MISRA C Working Group since its formation more than 10 years ago.
  • 5.
    © Programming Research 5 Agenda 1.An Introduction to MISRA C 2. The Changes in MISRA C:2012 3. Guideline Classification 4. MISRA C Compliance
  • 6.
    © Programming Research 6 MISRAC MISRA C:1998 • Derived from PRQA standards developed for Ford and Rover • Developed in UK for automotive applications MISRA C:2004 • Amended and extended • Supplemented with an Exemplar suite MISRA C:2012 • A committee of 10 representing many years of experience • 4 years of effort • Released 18th March 2013 • A further step forward …
  • 7.
    © Programming Research 7 Codingstandard adoption VDC Research White Paper* April 2011: “Re-evaluation of Development and Testing Practices April 2011” Available at: www.programmingresearch.com/whitepapers Data obtained from 600 respondents in Embedded and Enterprise/IT software and systems development. 0.0% 10.0% 20.0% 30.0% 40.0% Coding Standard Adoption by % of Respondents
  • 8.
    © Programming Research 8 MISRAC • Automotive • Aerospace • Defence • Medical • Nuclear power • Railways • Consumer electronics • Process control • etc. MISRA C is now the most widely used coding standard for the C language - worldwide
  • 9.
    © Programming Research 9 Agenda 1.An Introduction to MISRA C 2. The Changes in MISRA C:2012 3. Guideline Classification 4. MISRA C Compliance
  • 10.
    © Programming Research 10 TheChanges in MISRA C:2012 MISRA C:2012 compared to MISRA C:2004 • It's bigger – a few more rules (159 instead of 142 ) – and the content is better • Many guidelines are unchanged – they may be reworded and better specified – guideline/rule numbering has changed • Legacy code may not be compliant – there are new requirements – not many – but some restrictions have been removed
  • 11.
    © Programming Research 11 Clanguage support ISO:C90 • Well supported by compilers and tools • The dangers are well understood • Limitations – e.g. absence of Boolean type ISO:C99 • More features, e.g. _Bool and inline functions • More dangers, e.g. additional undefined behaviour • Most compilers do not support all features of C99 ISO:C11 • Still relatively new • Very limited tool support MISRA C:1998 MISRA C:2004 MISRA C:2012 MISRA C:2012
  • 12.
    © Programming Research 12 Guidelinespecification An expanded explanation of the requirement Why the guideline is necessary More extensive code examples Headline text clarification Exceptions
  • 13.
    © Programming Research 13 Terminology MISRAterminology has changed These terms were loosely defined and have been replaced The new terms are fully defined and used to describe expressions of any arithmetic type MISRA C:2004 MISRA C:2012 underlying type essential type complex expression composite expression effectively Boolean essentially Boolean
  • 14.
    © Programming Research 14 Agenda 1.An Introduction to MISRA C 2. The Changes in MISRA C:2012 3. Guideline Classification 4. MISRA C Compliance
  • 15.
    © Programming Research 15 Guidelineclassification Category • Advisory • Required • Mandatory Decidability • Decidable • Undecidable Language • C90 • C99 • C90, C99 Guideline Type • Directive • Rule Analysis Scope • Single Translation Unit • System
  • 16.
    © Programming Research 16 Rulesand Directives Rules – Have well defined requirements – Are statically enforceable (subject to certain limitations) Directives – May be loosely defined – allowing alternative interpretations – May address "process" or "documentation" requirements There are now 2 types of guideline:
  • 17.
    © Programming Research 17 Rulesand Directives - examples Rules Rule 8.5 An external object or function shall be declared once in one and only one file Rule 11.3 A cast shall not be performed between a pointer to object type and a different pointer to object type Dir 3.1 All code shall be traceable to documented requirements Dir 4.3 Assembly language shall be encapsulated and isolated Directives
  • 18.
    © Programming Research 18 Guidelinecategories • Advisory guidelines – These are recommendations – Non-compliance is permitted at the user's discretion – Non-compliance should be documented – Formal deviations are not required • Required guidelines – Non-compliance must be supported by a formal "deviation" • Mandatory guidelines – Must always be obeyed – Compliance is always required Mandatory guidelines were not a feature of previous versions of MISRA C There are now 3 guideline categories:
  • 19.
    © Programming Research 19 Ruledecidability A rule is decidable if it is always possible, in any program, for a tool to determine whether code is compliant. Otherwise the rule is undecidable Rules are either "decidable" or "undecidable" Rule 12.4 Evaluation of constant expressions should not lead to unsigned integer wrap-around Decidable … Undecidable … Rule 13.5 The right hand operand of a logical && or || operator shall not contain persistent side effects
  • 20.
    © Programming Research 20 Analysisscope There are 2 types of "analysis scope" Single Translation Unit Rules System Rules Rule 8.2 Function types shall be in prototype form with named parameters Rule 16.4 Every switch statement shall have a default label Rule 8.7 Functions and objects should not be defined with external linkage if they are referenced in only one translation unit Rule 13.5 The right hand operand of a logical && or || operator shall not contain persistent side efects
  • 21.
    © Programming Research 21 GuidelineClassification Summary CLASSIFICATION SUMMARY DIRECTIVES (16) RULES (143) CATEGORY Advisory 7 32 Required 9 101 Mandatory 0 10 LANGUAGE C90 0 2 C99 0 11 C90 or C99 16 130 DECIDABILITY Decidable - 117 Undecidable - 26 ANALYSIS SCOPE Single Translation Unit - 104 System - 39 Some rules are now classified as "mandatory" Some rules are only relevant for a specific language version Some rules cannot be statically enforced with certainty Rules that can be enforced within a single translation unit are decidable
  • 22.
    © Programming Research 22 Agenda 1.An Introduction to MISRA C 2. The Changes in MISRA C:2012 3. Guideline Classification 4. MISRA C Compliance
  • 23.
    © Programming Research 23 MISRAC Compliance • Enforceability • Decidability • Deviations What do we mean by "MISRA Compliant Code" ?
  • 24.
    © Programming Research 24 Enforceability 143 16 "Thevision for the third edition of MISRA C is therefore to: … Increase the number of guidelines that can be processed by static analysis tools" … MISRA C:2012 Chapter 1 – The Vision Rules - can be automatically enforced Directives – tools can sometimes assist with enforcement
  • 25.
    © Programming Research 25 Enforceability IndependentResearch performed by TERA-Labs, a new research division of the Karel de Grote university college in Antwerp, Belgium. • Test code was written for 11 key rules in MISRA C:2004 - selected by a panel of industrial partners • The test code was analysed using a number of analysis tools claiming to enforce compliancy with MISRA C • Two tool attributes were examined – Effectiveness in identifying rule violations – Incidence of false positive messages No False Positives Many False Positives All violations reported No violations reported GOOD BAD "The ability to detect the maximum number of violations possible, while minimizing the number of false positive messages, is therefore an important factor in choosing a tool." MISRA C:2012 Chapter 3.2 Analysis Tools
  • 26.
    © Programming Research 26 ToolEnforcement Tool XYZ The author of the TERA-Labs report observed: “On paper all the selected tools claimed to provide comprehensive MISRA C compliance checking – but the reality was different.” www.programmingresearch.com/resources/white-papers
  • 27.
    © Programming Research 27 MISRAC Compliance • Enforceability • Decidability • Deviations
  • 28.
    © Programming Research 28 Decidability "Inorder to use MISRA C, it is necessary to develop and document … • A compliance matrix, showing how compliance with each MISRA C guideline will be checked" MISRA C:2012 Chapter 5.2.1 – Process activities required by MISRA C "Where a guideline cannot be completely checked by a tool, then a manual review will be required." MISRA C:2012 Chapter 5.3 – Compliance 117 26 16 MISRA C:2012 Guidelines Decidable Rules Undecidable Rules Directives
  • 29.
    © Programming Research 29 MISRAC Compliance • Enforceability • Decidability • Deviations What do we mean by "MISRA Compliant Code" ?
  • 30.
    © Programming Research 30 Deviations "Inorder to use MISRA C, it is necessary to develop and document … • A deviation process by which justifiable non-compliances can be authorized and recorded " MISRA C:2012 Chapter 5.2.1 – Process activities required by MISRA C " It is important that such deviations are properly recorded and authorized." MISRA C:2012 Chapter 5.4 – Deviation procedure Deviations are often necessary … … but the process can also be abused MISRA C ADC: Approved deviation compliance for MISRA C:2004 ISBN 978-906400-09-5 (PDF), February 2013. Freely downloadable from www.misra.org.uk
  • 31.
    © Programming Research 31 DeviationManagement • Deviation support • Documentation • Collaborative code review • Baselining
  • 32.
  • 33.
    © Programming Research 33 Inconclusion … • Effective, accurate, automatic enforcement MISRA C 2012 QA C • Disciplined compliance and deviation management • Enforceable, decidable, well-specified coding rules
  • 34.
    © Programming Research 34 Doyou have any questions?
  • 35.
    © Programming Research 35 MISRAC:2012 microsite www.programmingresearch.com/mc3 • Download our MISRA C:2012 whitepaper • Share our 1-page MISRA C:2012 summary • Watch our videos about coding standards • Access the MISRA webstore
  • 36.
    © Programming Research 36 Doyou have any questions?
  • 37.
    © Programming Research 37 Thankyou Thank you for tuning in and giving an hour of your valuable time ! We will email the video link of this presentation and a summary of the Q&A shortly. Email us to ask any questions or for any follow-up points of interest. Paul Burden paul_burden@programmingresearch.com Please don’t forget to fill in our short survey to tell us how we did !

Editor's Notes

  • #4 NOTES The GoToMeeting attendee interface is made up of two parts. The Viewer Window is where attendees see the presenter’s screen. The Viewer Window can be resized by clicking and dragging the lower right corner. The Control Panel is where attendees can interact with organizers. Click 1, 2 and 3: Clicking the arrows on the Grab Tab opens and closes the Control Panel. Click 4: Audio pane provides audio information. If the organizer has given attendees a choice, there are two options. Attendees joined via VoIP (Use Mic & Speakers) need speakers to hear. Click 5 and 6: Attendees can also joined via telephone. Click 6: Attendees can communicate with organizers and other attendees through the Chat box (if enabled by the organizer). Click 7: In the View menu, uncheck “Auto-Hide the Control Panel” if attendees want their Control Panel to remain open.