QP/C++ MISRA-C++:2008 Compliance Matrix - Quantum Leaps

QP/C++ MISRA Compliance MatrixApplication NoteQP/C++ MISRA-C++:2008Compliance MatrixDocument Revision EOctober 2013Copyright © Quantum Leaps, LLCinfo@quantum-leaps.comwww.state-machine.comMISRA”, “MISRA C++”, and the triangle logo areregistered trademarks of MISRA Limited

Table of Contents1 Introduction ..................................................................................................................................................... 11.1 About MISRA-C++:2008 ........................................................................................................................... 11.2 About QP ............................................................................................................................................... 12 Checking MISRA-C++ Compliance with PC-Lint/FlexeLint .......................................................................... 22.1 Structure of PC-Lint Options for QP/C++ .................................................................................................. 22.2 The QP:: Namespace ............................................................................................................................... 72.3 QS Software Tracing and the Spy (Q_SPY) Configuration ....................................................................... 72.4 Checking MISRA Compliance of a QP/C++ Source Code ........................................................................ 72.5 Checking MISRA Compliance of a QP/C++ Application Code .................................................................. 83 MISRA-C++:2008 Compliance Matrix ............................................................................................................. 93.1 Unnecessary constructs ............................................................................................................................ 103.2 Storage ..................................................................................................................................................... 103.3 Runtime failures ........................................................................................................................................ 113.4 Arithmetic .................................................................................................................................................. 113.5 Language .................................................................................................................................................. 113.6 Character sets ........................................................................................................................................... 123.7 Trigraph sequence .................................................................................................................................... 123.8 Alternative tokens ..................................................................................................................................... 123.9 Comments ................................................................................................................................................. 123.10 Identifiers ................................................................................................................................................ 133.11 Literals .................................................................................................................................................... 133.12 Declarations and Definitions ................................................................................................................... 133.13 One Definition Rule ................................................................................................................................. 143.14 Declarative regions and scope ................................................................................................................ 143.15 Name lookup ........................................................................................................................................... 143.16 Types ...................................................................................................................................................... 143.17 Integer promotions .................................................................................................................................. 153.18 Pointer conversions ................................................................................................................................ 153.19 Expressions ............................................................................................................................................ 153.20 Postfix expressions ................................................................................................................................. 173.21 Unary expressions .................................................................................................................................. 183.22 Shift operators ......................................................................................................................................... 183.23 Logical AND operator .............................................................................................................................. 183.24 Assignment operators ............................................................................................................................. 183.25 Comma operator ..................................................................................................................................... 183.26 Constant expressions ............................................................................................................................. 193.27 Expression statement ............................................................................................................................. 193.28 Compound statement .............................................................................................................................. 193.29 Selection statements ............................................................................................................................... 203.30 Iteration statements ................................................................................................................................ 203.31 Jump statements ..................................................................................................................................... 213.32 Specifiers ................................................................................................................................................ 213.33 Enumeration declarations ....................................................................................................................... 213.34 Namespaces ........................................................................................................................................... 223.35 The asm declaration ............................................................................................................................... 223.36 Linkage specifications ............................................................................................................................. 223.37 Declarations — General .......................................................................................................................... 233.38 Meaning of declarations .......................................................................................................................... 233.39 Function definitions ................................................................................................................................. 233.40 Declarators — Initializers ........................................................................................................................ 233.41 Member functions ................................................................................................................................... 243.42 Unions ..................................................................................................................................................... 243.43 Bit-fields(1) .............................................................................................................................................. 243.44 Multiple base classes(1) .......................................................................................................................... 243.45 Member name lookup ............................................................................................................................. 253.46 Virtual Functions(1) ................................................................................................................................. 253.47 Constructors ............................................................................................................................................ 25Copyright © Quantum Leaps, LLC. All Rights Reserved.i

Application NoteQP/C MISRA-C:2004 Compliance Matrixstate-machine.com/qp3.48 Copying class objects ............................................................................................................................. 253.49 Template declarations(1) ........................................................................................................................ 263.50 Name resolution(1) ................................................................................................................................. 263.51 Template instantiation and specialization(1) ........................................................................................... 263.52 Function template specialization(1) ......................................................................................................... 263.53 Exception handling — General(1) ........................................................................................................... 273.54 Throwing an exception ............................................................................................................................ 273.55 Handling an exception ............................................................................................................................ 273.56 Exception specification ............................................................................................................................ 283.57 Exception handling — Special functions ................................................................................................. 283.58 Processing directives — General ............................................................................................................ 283.59 Conditional inclusion ............................................................................................................................... 293.60 Source file inclusion ................................................................................................................................ 293.61 Macro replacement ................................................................................................................................. 293.62 Pragma directive ..................................................................................................................................... 293.63 Library introduction — General ............................................................................................................... 303.64 Language support library — General(1) .................................................................................................. 303.65 Language support library — Implementation properties ......................................................................... 303.66 Language support library — Dynamic memory management ................................................................. 303.67 Language support library — Other runtime support ................................................................................ 313.68 Diagnostics library — Error numbers ...................................................................................................... 313.69 Input/Output library — General ............................................................................................................... 314 Beyond MISRA: Compliance with Additional Rules and Standards ........................................................... 324.1 Strong Type Checking .............................................................................................................................. 324.2 Quantum Leaps C/C++ Coding Standard ................................................................................................. 325 Deviation Procedures for QP/C++ Source Code ........................................................................................... 335.1 Rule 0-1-1(req) and 0-1-2(req) .................................................................................................................. 335.2 Rule 0-1-11(req) ........................................................................................................................................ 335.3 Rule 3-9-3(req) .......................................................................................................................................... 335.4 Rule 5-0-15(req) ........................................................................................................................................ 335.5 Rule 5-0-18(req) ........................................................................................................................................ 335.6 Rule 5-2-4(req) .......................................................................................................................................... 345.7 Rule 5-2-5(req) ......................................................................................................................................... 345.8 Rule 5-2-7(req) ......................................................................................................................................... 345.9 Rule 5-2-9(adv) ........................................................................................................................................ 345.10 Rule 5-2-10(adv) .................................................................................................................................... 345.11 Rule 7-1-1(req) ....................................................................................................................................... 345.12 Rule 8-5-1(req) ........................................................................................................................................ 355.13 Rule 9-5-1(req) ........................................................................................................................................ 355.14 Rule 16-0-4(req), 16-2-1(req), and 16-2-2(req) ....................................................................................... 355.15 Rule 16-2-1(req) and 16-2-2(req) ............................................................................................................ 355.16 Rule 16-3-2(adv) ..................................................................................................................................... 366 Deviation Procedures for Application-Level Code ....................................................................................... 366.1 Rule 5-2-6(req) ......................................................................................................................................... 366.2 Rule 5-2-7(req) .......................................................................................................................................... 366.3 Rule 5-2-8(req) .......................................................................................................................................... 376.4 Rule 6-4-3(req), 6-4-5(req), and 6-4-6(req) ............................................................................................... 377 Summary ...................................................................................................................................................... 398 Related Documents and References ............................................................................................................. 409 Contact Information ........................................................................................................................................ 41Copyright © Quantum Leaps, LLC. All Rights Reserved.ii

1 IntroductionThis Application Note describes the compliance of the QP/C++ state machine framework version 5.1.0or higher and the application code based on this framework with the Motor Industry Software ReliabilityAssociation (MISRA) Guidelines for the use of the C++ Language in Critical Systems [MISRA-C++:2008].This Application Note is designed to be applied to production code in safety-related embedded systems.1.1 About MISRA-C++:2008MISRA, the Motor Industry Software Reliability Association(www.misra.org.uk), is a collaboration between vehicle manufacturers,component suppliers, and engineering consultancies, which seeks topromote best practices in developing safety-related electronic systemsin road vehicles and other embedded systems.Since it's original publication in 1998 [MISRA-C:1998], the originalMISRA-C guidelines have gained an unprecedented level of acceptanceand use not only in the automotive industry, but in all kinds of embeddedsystems around the world. Following this initial success, in 2008 MISRApublished a set of rules for using C++ in safety-critical embeddedsystems, known as the MISRA-C++:2008.Due to the numerous idiosyncrasies, pitfalls, and undefined behavior ofthe standard C++ language, most experts agree that the full,unconstrained language should not be used for programming safetycriticalsystems. Consequently, the main objective of the MISRA-C++guidelines was to define and promote a safer subset of the C++language suitable for safety-related embedded systems. The [MISRA-C++:2008] guidelines define this language subset by means of 229 rulesthat restrict the use of the known problematic aspects of the language. For each of the rules the MISRA-C++ guidelines provide justification and examples.1.2 About QPQP/C++ is a lightweight, open source, state machine framework fordeveloping event-driven embedded software. The QP/C++ frameworkenables software developers to build well-structured embeddedapplications as systems of concurrently executing hierarchical statemachines (UML statecharts). QP has been described in great detail inthe book Practical UML Statecharts in C/C++, Second Edition: Event-Driven Programming for Embedded Systems [PSiCC2 08] (Newnes,2008).The use of a tested framework, such as QP/C++, addresses thegrowing concern over the robustness of the design, not just the codingaspects of safety-critical software. To this end, a framework based onthe proven concepts of state machines and active objects provides amore robust and safer design platform than a primitive “super-loop” oran unstructured design based on a traditional Real-Time OperatingSystem (RTOS). The QP/C framework enforces safe design andencapsulates or eliminates the troublesome RTOS mechanisms, suchas semaphores, which many programmers do not use correctly orsafely.Copyright © Quantum Leaps, LLC. All Rights Reserved.1 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp2 Checking MISRA-C++ Compliance with PC-Lint/FlexeLintThe [MISRA-C++:2008] guidelines place great emphasis on the use of static code analysts tools tocheck compliance with the MISRA-C++ language subset. In fact, the automatic enforcement of as manyrules as possible is mandated by MISRA-C++:2008 required rule 0-3-1.NOTE: The completely automatic enforcement of 100% of the MISRA-C++ rules is not possible andwas never intended. Some of the rules are only enforceable by manual review of the code orchecking the compiler/linker tools by other means.This Application Note uses PC-Lint/FlexeLint version 9.00k from Gimpel Software [www.Gimpel.com],which is a static analysis tool for C and C++ with one of the longest track records and best value of themoney in the industry. PC-Lint has been supporting checks for the MISRA-C guidelines since early 2001,and MISRA-C++ since 2009. The company is committed to provide ongoing and increasing support forthese guidelines (see [PC-Lint 08]).The primary way of activating MISRA checking for MISRA-C++:2008 guidelines in PC/Lint is via theoption file [PC-Lint/MISRA-C++:2008]:au-misra-cpp.lntThis file contains the options to activate and annotate PC-Lint messages dealing with MISRA-C++:2008.PC-Lint can report deviations from several MISRA C++ rules with messages 1960 and 1963. Additionalrules, are covered in other messages, the details of which you can find listed in the au-misra-cpp.lntfile.NOTE: The au-misra-cpp.lnt configuration file is also the best overall documentation onMISRA-C++:2008 coverage, including not just which rules are covered, but also how they arechecked and what messages are produced.2.1 Structure of PC-Lint Options for QP/C++PC-Lint has several places where it reads its currently valid options:• From special Lint option files (usually called *.lnt)• From the command line• From within the special lint-comments in the source code modules (not recommended)The QP/C++ source code and example application code has been “linted” only by means of the firstalternative (option files) with possibility of adding options via command line. The third alternative—lintcomments—is not used and Quantum Leaps does not recommend this alternative.NOTE: The QP/C++ source code is completely free of lint comments, which are viewed as acontamination of the source code.The structure of the PC-Lint option files used for “linting” QP/C++ follows exactly the Gimpel Softwareguidelines for configuring PC-Lint (See Section 3.2 “Configuration” in the PC-Lint/FlexeLint Manual). Thedesign and grouping of the lint options also reflects the fact that static code analysis of a softwareframework, such as QP/C++, has really two major aspects. First, the source code of the framework itselfhas to be analyzed. But even more important and helpful to the users of the framework is providing theinfrastructure to effectively analyze the application-level code based on the framework. With this in mind,Listing 1 shows that the PC-Lint options for static analysis of QP/C++ are divided into two groups, locatedCopyright © Quantum Leaps, LLC. All Rights Reserved.2 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qpin directories qpcpp\include\ and qpcpp\ports\lint\. These two groups are for analyzing QP/C++applications and QP/C++ source code, respectively.Listing 1: PC-Lint options for “linting” QP/C++ applications (qpcpp\include\)and “lining” QP/C++ source code itself (qpcpp\ports\lint\).%QPCPP%\- QP/C++ Root Directory (environment variable QPCPP)|+-include\- QP/C++ platform-independent includes| +-au-ds.lnt - Dan Saks recommendations| +-au-misra-cpp.lnt - Main PC-Lint MISRA-C++:2008 compliance options| +-lib-qpcpp.lnt - PC-Lint options for QP/C++ applications| +-std.lnt - Standard PC-Lint settings recommended by Quantum Leaps| +-qassert.h - QP/C++ header file| +-qep.h - QP/C++ header file| +-. . . - . . .| || +-ports\ - QP/C++ ports directory| | +-lint\ - QP/C++ “port” to PC-Lint| | | +-lin.bat - Batch file to invoke PC-Lint to run analysis of QP/C++ code| | | +-options.lnt - PC/Lint options for “linting” QP/C++ source code| | | +-lint_qep.txt - PC/Lint output for the QEP component of QP/C++| | | +-lint_qf.txt - PC/Lint output for the QF component of QP/C++| | | +-lint_qk.txt - PC/Lint output for the QK component of QP/C++| | | +-lint_qs.txt - PC/Lint output for the QS component of QP/C++| | | +-qep_port.h - QEP component “port” to a generic ANSI C++ compiler| | | +-qf_port.h - QF component “port” to a generic ANSI C++ compiler| | | +-qk_port.h - QK component “port” to a generic ANSI C++ compiler| | | +-qs_port.h - QS component “port” to a generic ANSI C++ compiler| | | +-stdint.h - Standard exact-width integers for an ANSI C++ compiler| || +-examples\ - QP/C++ examples directory| | +-arm-cortex\ - QP/C++ examples for ARM Cortex| | | +-qk\ - QP/C++ examples for ARM Cortex with QK kernel| | | | +-gnu\ - QP/C++ examples with GNU compiler| | | | | +-dpp-qk-ev-lm3s811-lint\ - Lint-compatible example for GNU| | | | +-iar\ - QP/C++ examples with IAR compiler| | | | | +-dpp-qk-ev-lm3s811-lint\ - Lint-compatible example for IARNOTE: This Application Note assumes that the baseline distribution of the QP/C++ framework hasbeen downloaded and installed and that the environment variable QPCPP has been defined to pointto the QP/C++ installation directory.As shown in Listing 1, the directory %QPCPP%\include\, contains the PC-Lint options for “linting” theapplication code along with all platform-independent QP/C++ header files required by the applications.This collocation of lint options with header files simplifies “linting”, because specifying just -i%QPCPP%\include\ include directory to PC-Lint accomplishes both inclusion of QP/C++ header files and PC-Lintoptions.Note that the %QPCPP%\include\ directory contains all PC-Lint option files used in “linting” the code,including the standard MISRA-C++:2008 au-misra-cpp.lnt option file as well as Dan Saks'recommendations au-ds.lnt, which are copied from the PC-Lint distribution. This design freezes the lintoptions for which the compliance has been checked.Copyright © Quantum Leaps, LLC. All Rights Reserved.3 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp2.1.1 The std.lnt option fileAccording to the Gimpel Software PC-Lint configuration guidelines, the file %QPC%\include\std.lnt file,shown in Listing 2,contains the top-level options, which Quantum Leaps recommends for all projects.These options include the formatting of the PC-Lint messages and making two passes to perform bettercross-module analysis. However, the most important option is -restore_at_end, which has the effect ofsurrounding each source file with options -save and -restore. This precaution prevents options from“bleeding” from one file to another.Listing 2: Top-level option file std.lnt// output: a single line, file info always, use full path names-hF1+ffn-"format=%(\q%f\q %l %C%) %t %n: %m"-width(0,0)+flm-zero(99)-passes(2)-restore_at_end-summary()// do not break lines// make sure no foreign includes change the format// don't stop make because of warnings// make two passes (for better error messages)// don't let -e options bleed to other files// produce a summary of all produced messages2.1.2 The lib-qpcpp.lnt option fileThe most important file for “linting” QP/C++ applications is the lib-qpcpp.lnt option file. This filehandles all deviations from the MISRA-C++:2008 rules, which might arise at the application-level codefrom the use of the QP/C++ framework. In other words, the lib-qpcpp.lnt option file allows completelyclean “linting” of the application-level code, as long as the application code does not deviate from any ofthe MISRA-C++:2008 rules.At the same time, the lib-qpcpp.lnt option file has been very carefully designed not to suppress anyMISRA-C++:2008 rule checking outside the very specific context of the QP/C++ API. In other words, thelib-qpcpp.lnt option file still supports 100% of the MISRA-C++:2008 rule checks that PC-Lint iscapable of performing.For example, for reasons explained in Section 5.12, QP/C++ extensively uses function-like macros, whichdeviates from the MISRA-C++:2008 advisory rule 19.7 and which PC-Lint checks with the warning 961.However, instead of suppressing this warning globally (with the -e961 directive), the lib-qpcpp.lntoption file suppresses warning 961 only for the specific QP function-like macros that are visible to theapplication level. So specifically, the lib-qpcpp.lnt file contains directives -estring(961, Q_TRAN,Q_SPUER, ...), which suppresses the warning only for the specified macros, but does not disablechecking of any other macros in the application-level code.// general (event.h)-estring(1960,sig,poolId_,refCtr_)Listing 3: file lib-qpcpp.lnt// 11-0-1(req) non-private data memberCopyright © Quantum Leaps, LLC. All Rights Reserved.4 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp-estring(1927,// 8-5-1(req) not in the ctor initializer*QEvt::poolId_,*QEvt::refCtr_)-estring(1923,// 16-2-2(req) could become const variableQ_EVT_CTOR,Q_SIGNAL_SIZE,QP_VERSION)-emacro(923, Q_UINT2PTR_CAST) // 5-2-7, 5-2-8 cast from int to pointer-estring(1960,// 16-0-4(req) function-like macroQ_DIM,Q_UINT2PTR_CAST)-esym(1790,// Base class has no virtual functions*QEvt)-estring(1712, QEvt) // default constructor not defined-estring(1401,// member not initialized in the ctor*QEvt::poolId_,*QEvt::refCtr_)-emacro(866, Q_DIM) // Unusual use of 'SYM' in argument to sizeof-estring(970,bool) // Use of 'bool' outside of a typedef// Assertions-estring(1960,// 16-0-4 function-like macroQ_ASSERT,. . .Q_DEFINE_THIS_MODULE). . .-function(exit, Q_onAssert) // give Q_onAssert() the semantics of "exit"// QEP-emacro(929,// 5-2-7(req) cast pointer to pointerQ_STATE_CAST,Q_EVENT_CAST)-emacro(1939,// 5-2-2, Down cast detectedQ_EVT_CAST,Q_NEW,Q_NEW_X)-estring(1960,*QMAttr) // 9-5-1 declaration of union-esym(1960,// 16-0-4 function-like macroQ_ROM_BYTE,Q_TRAN,Q_SUPER,Q_STATE_CAST,Q_EVENT_CAST)-esym(1712,// default constructor not definedQFsm,QHsm)// QF-emacro(929, Q_NEW)-esym(1927,*QActive::m_prio,*QActive::m_eQueue,*QActive::m_osObject,*QActive::m_thread)-estring(1923,// 5-2-7 cast from pointer to pointer// 8-5-1 Symbol not in the ctor initializer list// 16-2-2 could become const variableCopyright © Quantum Leaps, LLC. All Rights Reserved.5 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qpQF_MAX_ACTIVE,. . .)-esym(1960,// 16-0-4 function-like macroQF_QS_CRIT_EXIT,. . .)-estring(1963, Q_NEW) // 16-3-2(adv) '#/##' used in macro-esym(1790,// Base class has no virtual functions*QHsm,*QFsm,*QActive)-esym(1401,// member not initialized by constructor*QActive::m_prio,*QActive::m_eQueue,*QActive::m_osObject,*QActive::m_thread)-esym(1712,// default constructor not defined for class*QActive,*QTimeEvt)-esym(641, *Signals) // Converting enum '*Signals' to 'int'// QK-esym(1960,QK_ISR_ENTRY,. . .)// 16-0-4 function-like macro// QS-emacro(506, QS_*) // 0-1-1 constant value boolean-emacro(774, QS_*) // 0-1-1 'if' always True-emacro(930, QS_*) // 5-2-7 cast from enum to unsigned char-emacro(923,// 5-2-7, 5-2-8 cast from pointer to intQS_OBJ_,QS_FUN_)-estring(1923, // 16-2-2 macro could become const variableQS_TIME_SIZE,. . .)-esym(1960,// 16-0-4 function-like macro. . .)-esym(1923,// 16-2-2 could become const variableQS_INIT,QS_EXIT,. . .)-esym(1963,// 16-3-2, '#/##' operator used in macroQS_SIG_DICTIONARY,. . .)-emacro(717, QS_*) // do ... while(0);-emacro(725, QS_END*) // Expected positive indentation-esym(641, *QSType) // Converting enum '*QSType' to 'int'// Miscallaneous-estring(793,6) // ANSI/ISO limit of 6 significant chars exceeded-e546 // Suspicious use of &NOTE: Any changes to the PC-Lint option files (e.g., as part of upgrading PC-Lint) must be done withcaution and must be always followed by regression analysis of all source code.Copyright © Quantum Leaps, LLC. All Rights Reserved.6 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp2.2 The QP:: NamespaceThe MISRA-C++:2008 group of required rules 7-3-x (“Namespaces”) is concerned with avoiding nameconflicts by applying C++ namespaces. To comply with these rules, QP/C++ source code must beconfigured to place all declarations and definitions in the QP:: namespace. Starting with QP/C++ version4.5.02 QP/C++ applies the QP:: namespace by defining default.Please note also that compliance with the rules 7-3-x requires also the application-level code to use aspecific namespace as opposed to contaminate the global namespace. The application-level code caneither extend the QP:: namespace, or it can use its own distinct namespace. Either way, all QP elementsmust be explicitly qualified with the QP:: namespace prefix, as the “using namespace QP” directive isnot allowed by the required rules 7-3-4, 7-3-5, and 7-3-6.NOTE: To comply with MISRA-C++:2008, the applications must explicitly qualify all QP/C++elements with the QP:: namespace prefix. The MISRA-compliant application examples (see Listing1) show how to use the QP:: namespace prefix.2.3 QS Software Tracing and the Spy (Q_SPY) ConfigurationAs described in Chapter 11 of the book “Practical UML Statecharts in C/C++” [PSiCC2], all components ofthe QP/C++ framework contain software tracing instrumentation (called Quantum Spy, or QS). Thisinstrumentation code is inactive in the Debug and Release build configurations, but becomes active in theSpy configuration.In the context of MISRA-C++ compliance it is important to note that, by the nature of software tracing, theQS code embedded in the QP/C++ framework contributes disproportionately to the total number ofdeviations from the MISRA-C++ rules, both in the QP/C++ source code and in the application-level code.However, these deviations occur only in the Spy build configuration, which is not the code shipped withina product.NOTE: Many of the deviations from the MISRA-C++:2008 rules reported in the upcoming MISRACompliance Matrix do not pertain to the production code.2.4 Checking MISRA Compliance of a QP/C++ Source CodeThe directory %QPCPP%\ports\lint\ (see Listing 1) contains the lin.bat batch file for “linting” theQP/C++ source code. The lin.bat batch file invokes PC-Lint and directs it to generate the diagnostic tospecific output files. As shown in Listing 1, the lint output is collected into four text files lint_qep.txt,lint_qf.txt, lint_qk.txt, and lint_qs.txt, for QEP, QF, QK, and QS components of the QP/C++framework, respectively.NOTE: In order to execute the lin.bat file on your system, you might need to adjust the symbolPC_LINT_DIR at the top of the batch file, to the PC-Lint installation directory on your computer.The lin.bat batch file invoked without any command-line options checks the code in the defaultconfiguration corresponding to Run or Debug build of a project. But the lin.bat batch can also beinvoked with the option -dQ_SPY to check the QP/C++ code in the QS configuration with software tracing.NOTE: By the nature of software tracing, the Q_SPY configuration transgresses many more MISRA-C++:2008 rules than the standard configuration. However, the Q_SPY configuration is never used forCopyright © Quantum Leaps, LLC. All Rights Reserved.7 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qpproduction code, so the MISRA-C++ compliance of the QP/C++ framework should not be judged bythe deviations that happen only in the Q_SPY configuration.According to the PC-Lint guidelines, the lin.bat uses two option files: the std.lnt option file discussedbefore and the options.lnt option file that covers all deviations from the MISRA-C++ rules in the QP/C++ source code. Section 3 (MISRA compliance matrix) cross-references all these deviations, while Section5 (deviation procedures) describes the reasons for deviations in those, very specific contexts.2.5 Checking MISRA Compliance of a QP/C++ Application CodeThe QP/C++ baseline code (for versions QP/C++ 4.4.00 and higher) contains two examples of MISRA-C++ compliance checking with PC/Lint:• The DPP example for the EK-LM3S811 Cortex-M3 board with the IAR ARM compiler, located in thedirectory qpcpp\examples\arm-cortex\qk\iar\dpp-qk-ev-lm3s811-lint\; and• The DPP example for the EK-LM3S811 Cortex-M3 board with the GNU ARM compiler, located in thedirectory qpcpp\examples\arm-cortex\qk\gnu\dpp-qk-ev-lm3s811-lint\.The PC-Lint analysis is very simple and requires invoking the lin.bat file from the lint\ subdirectory ineach of the application folders.NOTE: In order to execute the lin.bat file on your system, you might need to adjust the symbolPC_LINT_DIR at the top of the batch file, to the PC-Lint installation directory on your computer. YouThe lint\ subdirectory in each of the application folders contains also the options.lnt with the PC-Lintoptions specific to linting the application. This file specifies the include directory for the specific embeddedcompiler used to compile the application, and you most likely need to adjust it for your system.Running PC-Lint on embedded projects (such as the DPP example for ARM Cortex-M) requires optionfiles for the specific compilers (co-iar-arm.lnt file for IAR ARM and co-gnu-arm.lnt file GNU ARM,respectively). These option files are provided in the Qtools collection. The location of the Qtools directoryin your system is specified in the options.lnt file, and you most likely need to adjust it for your system.NOTE: The Qtools collection is available for a separate download from http://www.statemachine.com/downloads/index.php#QTools.Quantum Leaps is committed to keep adding more andmore PC-Lint option files for various embedded C/C++ cross-compilers in the Qtools collection.Copyright © Quantum Leaps, LLC. All Rights Reserved.8 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3 MISRA-C++:2008 Compliance MatrixAs recommended in Section 4.3.1 of the [MISRA-C++:2008] guidelines, this section presents thecompliance matrix, which lists each MISRA-C++:2008 rule and indicates the compliance status and howthe rule has been checked. The meaning of the compliance matrix columns is as follows:1. Rule No. column lists the MISRA-C++:2008 rule number followed by the rule classification inparentheses (req) for required rule and (adv) for advisory rule.2. PC-Lint column lists whether a rule is checked by PC-Lint/au-misra-cpp.lnt. The checked rulesare marked with a check-mark (). Empty status (), also clearly marked by the yellow background,means that the rule is not checked by PC-Lint and requires a manual review.NOTE: The ability of PC-Lint to check a MISRA-C++:2008 rule is determined by means of twosources (1) the Gimpel Software matrix [PC-Lint-MISRA-C++:2008] and (2) the test against the actualcode. When in doubt, the rules are marked as not-checked by PC-Lint.3. QP/C++ column lists the compliance status of the QP/C++ source code. Letters A or M in this columnmean that the QP/C++ framework source code complies with the rule, whereas A means that the rulehas been checked automatically (via PC-Lint), and M means that the rule has been verified manually.A number in this column (clearly marked by the orange background) indicates a deviation from therule. The number is the subsection number within the section Deviation Procedures for QP/C++Source Code, which describes in detail the nature and particular circumstances of the deviation.4. QP/C++ app. column lists the deviations of the QP/C++ application-level code imposed by theQP/C++ framework. No entry in this column indicates that QP/C++ imposes or no deviations,meaning that the application-level code can be made compliant with the rule. However, for somerules (clearly marked by the red background in this column) the design and/or the implementation ofthe QP/C++ framework imposes a deviation from the rule, in which case the column lists thesubsection number within the section Deviation Procedures for Application-Level Code. Finally, casesthat the QP/C++ might impose a deviation, but a workaround exists, are clearly marked with theblue background in this column.5. Description column contains a short description of the rule, as published in Appendix A of the[MISRA-C++:2008] guidelines.Copyright © Quantum Leaps, LLC. All Rights Reserved.9 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.1 Unnecessary constructsRule No.PC-LintQP/C++QPapp.Description0-1-1(req) 5.1 (1) 5.1 (1) A project shall not contain unreachable code.0-1-2(req) 5.1 (1) 5.1 (1) A project shall not contain infeasible paths.0-1-3(req) A A project shall not contain unused variables.0-1-4(req) AA project shall not contain non-volatile POD variables having only oneuse0-1-5(req) A A project shall not contain unused type declarations0-1-6(req) A0-1-7(req) AA project shall not contain instances of non-volatile variables beinggiven values that are never subsequently used.The value returned by a function having a non-void return type that isnot an overloaded operator shall always be used0-1-8(req) A All functions with void return type shall have external side-effects0-1-9(req) A There shall be no dead code0-1-10(req) A Every defined function shall be called at least once0-1-11(req) 5.2There shall be no unused parameters (named or unnamed) in nonvirtualfunctions.There shall be no unused parameters (named or unnamed) in a virtual0-1-12(req) Afunction and all the functions that override it.(1)QP/C++ deviates from this rule only in the QS macros in the Q_SPY configuration3.2 StorageRule No.PC-LintQP/C++QPapp.Description0-2-1(req) A An object shall not be assigned to an overlapping objectCopyright © Quantum Leaps, LLC. All Rights Reserved.10 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.3 Runtime failuresRule No.PC-LintQP/C++QPapp.Description0-3-1(doc) A (1) (1) Minimization of run-time failures shall be ensured by the use of at leastone of:(a) static analysis tools/techniques;(b) dynamic analysis tools/techniques;(c) explicit coding of checks to handle run-time faults.0-3-2(req) A (2) (2) If a function generates error information, then that error informationshall be tested.(1)The QP/C++ framework uses static analysis tool (PC-Lint) and explicit coding of checks (assertions).For compliance with this rule, application-level code needs to use static analysis tool as well.(2)The QP/C++ framework uses assertions except of error returns.3.4 ArithmeticRule No.PC-LintQP/C++QPapp.Description0-4-1(doc) M (1) Use of scaled-integer of fixed-point arithmetic shall be documented.0-4-2(doc) M (1) Use of floating-point arithmetic shall be documented.0-4-3(doc) M (1) Floating-point implementations shall comply with a defined floatingpointstandard.(1)QP/C++ does not use scaled-integers or floating-point arithmetic3.5 LanguageRule No.PC-LintQP/C++1-0-1(req) AQPapp.DescriptionAll code shall confirm to ISO/IEC 14882:2003 “The C++ StandardIncorporating Technical Corrigendum 1”.1-0-2(doc) M (1) Multiple compilers shall only be used if they have a common, definedinterface.1-0-3(doc) M (2) The implementation of integer division in the chosen compiler shall bedetermined and documented.(1)Selected QP/C++ ports might require assembly modules. In all such cases a documented interfacestandard, such as APCS (ARM Procedure Calling Standard) are observed.(2)QP/C++ does not use integer division or modulo operation anywhere in the code. (QP/C++ does notuse even integer multiplication.)Copyright © Quantum Leaps, LLC. All Rights Reserved.11 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.6 Character setsRule No.PC-LintQP/C++QPapp.Description2-2-1(doc) M (1) The character set and the corresponding encoding shall bedocumented.(1)QP/C++ source code uses only ASCII character set3.7 Trigraph sequenceRule No.PC-LintQP/C++QPapp.2-3-1(req) A Trigraphs shall not be used.Description3.8 Alternative tokensRule No.PC-LintQP/C++QPapp.2-5-1(adv) A Digraphs should not be used.Description3.9 CommentsRule No.PC-LintQP/C++QPapp.Description2-7-1(req) A (1) The character sequence /* shall not be used within a C-style comment2-7-2(req) M Sections of code shall not be “commented out” using C-style comments2-7-3(adv) M Sections of code shall not be “commented out” using C++ comments.(1)QP/C++ source code does not use the C-style comments, except in a few comments for multi-lineassertions, where some compilers generated errors when C++ comments were used.Copyright © Quantum Leaps, LLC. All Rights Reserved.12 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.10 IdentifiersRule No.PC-LintQP/C++QPapp.Description2-10-1(req) (1) A Different identifiers shall be typographically unambiguous.2-10-2(req) A2-10-3(req) M2-10-4(req) M2-10-5(adv) MIdentifiers declared in an inner scope shall not hide an identifierdeclared in an outer scope.A typdef name (including qualification, if any) shall be a uniqueidentifier.A class, union, or enum name (including qualification, if any) shall beunique identifier.The identifier name of a non-member object or function with staticstorage duration should not be reused.If an identifier refers to a type, it shall not also refer to an object or a2-10-6(req) Afunction in the same scope.(1)The PC-Lint matrix indicates “partial” checking of this rule3.11 LiteralsRule No.PC-LintQP/C++QPapp.Description2-13-1(req) A2-13-2(req) A2-13-3(req) AOnly those escape sequences that are defined in ISO/IEC 14882:2003shall be used.Octal constants (other than zero) and octal escape sequences (otherthan '\0') shall not be used.A “U” suffix shall be applied to all octal or hexadecimal integer literals ofunsigned type.2-13-4(req) A Literal suffixes shall be upper case.2-13-5(req) A Narrow and wide string literals shall not be concatenated.3.12 Declarations and DefinitionsRule No.PC-LintQP/C++QPapp.Description3-1-1(req) AIt shall be possible to include any header file in multiple translation unitswithout violating the One Definition Rule.3-1-2(req) A Functions shall not be declared at block scope.3-1-3(req) AWhen an array is declared, its size shall either be stated explicitly ordefined implicitly by initialization.Copyright © Quantum Leaps, LLC. All Rights Reserved.13 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.13 One Definition RuleRule No.PC-LintQP/C++QPapp.Description3-2-1(req) A All declarations of an object or function shall have compatible types3-2-2(req) A The One Definition Rule shall not be violated3-2-3(req) AA type, object or function that is used in multiple translation units shallbe declared in one and only one file.3-2-4(req) A An identifier with external linkage shall have exactly one definition.3.14 Declarative regions and scopeRule No.PC-LintQP/C++3-3-1(req) A3-3-2(req) AQPapp.DescriptionObjects and functions with external linkage shall be declared in aheader fileIf a function has internal linkage then all re-declarations shall includethe static storage class specifier.3.15 Name lookupRule No.PC-LintQP/C++3-4-1(req) MQPapp.DescriptionAn identifier declared to be an object or type shall be defined in a blockthat minimizes its visibility.3.16 TypesRule No.PC-LintQP/C++3-9-1(req) MQPapp.DescriptionThe types used for an object, a function return type, or a functionparameter shall be token-for-token identical in all declarations and redeclarations.3-9-2(adv) A (1) typedefs that indicate size and signedness should be used in place ofthe basic numerical types.3-9-3(req) 5.3 (2) The underlying bit representations of floating-point values shall not beused.(1)QP/C++ uses the standard exact-with integer types stdint.h (WG14/N843 C99, Section 7.18.1.1)(2)QP/C++ deviates from this rule only in QS software tracing implementation for binary output of floatingpointvalues.Copyright © Quantum Leaps, LLC. All Rights Reserved.14 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.17 Integer promotionsRule No.PC-LintQP/C++4-5-1(req) A4-5-2(req) M4-5-3(req) AQPapp.DescriptionExpressions with type bool shall not be used as operands to built-inoperators other than the assignment operator =, the logical operators&&, ||, !, the equality operators == and !=, the unary & operator, andthe conditional operator.Expressions with type enum shall not be used as operands to built-inoperators other than the subscript operator [ ], the assignmentoperator =, the equality operators == and !=, the unary & operator, andthe relational operators =.Expressions with type (plain) char and wchar_t shall not be used asoperands to built-in operators other than the assignment operator =, theequality operators == and !=, and the unary & operator.3.18 Pointer conversionsRule No.PC-LintQP/C++QPapp.Description4-10-1(req) M (1) NULL shall not be used as an integer value.4-10-2(req) A Literal zero (0) shall not be used as the null-pointer-constant.(1)QP/C++ source code does not use the NULL literal anywhere in the code(1)QP/C++ source code uses the strongly-typed, specifically cast pointer literals, e.g., static_cast(0);3.19 ExpressionsRule No.PC-LintQP/C++5-0-1(req) A5-0-2(adv) A5-0-3(req) A5-0-4(req) AQPapp.DescriptionThe value of an expression shall be the same under any order ofevaluation that the standard permits.Limited dependence should be placed on C++ operator precedencerules in expressions.A cvalue expression shall not be implicitly converted to a differentunderlying type.An implicit integral conversion shall not change the signedness of theunderlying type.5-0-5(req) A There shall be no implicit floating-integral conversions.5-0-6(req) A5-0-7(req) A5-0-8(req) An implicit integral or floating-point conversion shall not reduce the sizeof the underlying type.There shall be no explicit floating-integral conversions of a cvalueexpression.A An explicit integral or floating-point conversion shall not increase theCopyright © Quantum Leaps, LLC. All Rights Reserved.15 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qpRule No.PC-LintQP/C++QPapp.Descriptionsize of the underlying type of a cvalue expression.5-0-9(req) A5-0-10(req) A5-0-11(req) AAn explicit integral conversion shall not change the signedness of theunderlying type of a cvalue expression.If the bitwise operators ~ and , >=,

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.20 Postfix expressionsRule No.PC-LintQP/C++QPapp.Description5-2-1(req) A Each operand of a logical && or || shall be a postfix-expressoin.5-2-2(req) (1) A (1) A pointer to a virtual base class shall only be cast to a pointer to aderived class by means of dynamic_cast.5-2-3(adv) MCasts from a base class to a derived class should not be performed onpolymorphic types.5-2-4(req) 5.6 (2) C-style casts (other than void casts) and functional notation casts(other than explicit constructor calls) shall not be used.5-2-5(req) 5.75-2-6(req) A 6.15-2-7(req) 5.8 6.2A cast shall not remove any const or volatile qualification from thetype of a pointer or reference.A cast shall not convert a pointer to a function to any other pointertype, including a pointer to function type.An object with pointer type shall not be converted to an unrelatedpointer type, either directly or indirectly.5-2-8(adv) A 5.6 (2) An object with integer type or pointer to void type shall not beconverted to an object with pointer type.5-2-9(adv) 5.9 A cast should not convert a pointer type to an integral type.5-2-10(adv) 5.105-2-11(req) AThe increment (++) and decrement (--) operators should not be mixedwith other operators in an expression.The comma operator, && operator and the || operator shall not beoverloaded.An identifier with array type passed as a function argument shall not5-2-12(req) Adecay to a pointer.(1)PC-Lint reports any down-cast as violation of the rule 5-2-2. The QP/C++ source code provides macroQ_EVENT_CAST() for performing downcasting of events from the QEvt base class to the specific userdefinedderived class.(2)QP/C++ source code uses predominantly C++ style casts. The C-style casts are used only in code thatis likely to be used in C modules, such as QP/C++ assertions (qassert.h header file).(3)QP/C++ provides macro Q_UNIT2PTR_CAST(), which could be used in the QP/C++ applications toaccess specific hardware registers.Copyright © Quantum Leaps, LLC. All Rights Reserved.17 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.21 Unary expressionsRule No.PC-LintQP/C++5-3-1(req) A5-3-2(req) AQPapp.DescriptionEach operand of the ! operator, the logical && or the logical ||operators shall have type bool.The unary minus operator shall not be applied to an expression whoseunderlying type is unsigned.5-3-3(req) A The unary & operator shall not be overloaded.5-3-4(req) AEvaluation of the operand to the sizeof operator shall not contain sideeffects.3.22 Shift operatorsRule No.PC-LintQP/C++5-8-1(req) AQPapp.DescriptionThe right hand operand of a shift operator shall lie between zero andone less than the width in bits of the underlying type of the left handoperand.3.23 Logical AND operatorRule No.PC-LintQP/C++5-14-1(req) AQPapp.DescriptionThe right hand operand of a logical && or || operator shall not containside effects.3.24 Assignment operatorsRule No.PC-LintQP/C++QPapp.Description5-17-1(req) M (1) The semantic equivalence between a binary operator and itsassignment operator form shall be preserved.(2)QP/C++ does not overload any operators.3.25 Comma operatorRule No.PC-LintQP/C++QPapp.Description5-18-1(req) A The comma operator shall not be used.Copyright © Quantum Leaps, LLC. All Rights Reserved.18 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.26 Constant expressionsRule No.PC-LintQP/C++5-19-1(adv) AQPapp.DescriptionEvaluation of constant unsigned integer expressions should not lead towrap-around.3.27 Expression statementRule No.PC-LintQP/C++QPapp.Description6-2-1(req) A Assignment operators shall not be used in sub-expressions.6-2-2(req) A6-2-3(req) AFloating-point expressions shall not be directly or indirectly tested forequality or inequality.Before preprocessing, a null statement shall only occur on a line byitself; it may be followed by a comment, provided that the first characterfollowing the null statement is a white-space character.3.28 Compound statementRule No.PC-LintQP/C++6-3-1(req) AQPapp.DescriptionThe statement forming the body of a switch, while, do ... whileor for statement shall be a compound statement.Copyright © Quantum Leaps, LLC. All Rights Reserved.19 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.29 Selection statementsRule No.PC-LintQP/C++6-4-1(req) A6-4-2(req) AQPapp.DescriptionAn if ( condition ) construct shall be followed by a compoundstatement. The else keyword shall be followed by either a compoundstatement, or another if statement.All if … else if constructs shall be terminated with an elseclause.6-4-3(req) M 6.4 (1) A switch statement shall be a well-formed switch statement.6-4-4(req) MA switch-label shall only be used when the most closely-enclosingcompound statement is the body of a switch statement.6-4-5(req) A 6.4 (1) An unconditional throw or break statement shall terminate everynon-empty switch-clause.6-4-6(req) A 6.4 (1) The final clause of a switch statement shall be the default-clause.6-4-7(req) A The condition of a switch statement shall not have bool type.6-4-8(req) A Every switch statement shall have at least one case-clause.(1)The published examples of state machine implementations with QP/C++ deviate from MISRA-C++ rules6-4-3, 6-4-5, and 6-4-6. However, a fully compliant implementation is also possible and is described inSection 6.4.3.30 Iteration statementsRule No.PC-LintQP/C++6-5-1(req) M6-5-2(req) MQPapp.DescriptionA for loop shall contain a single loop-counter which shall not havefloating type.If loop-counter is not modified by -- or ++, then, within condition, theloop-counter shall only be used as an operand to =.6-5-3(req) A The loop-counter shall be modified within condition statement.6-5-4(req) M6-5-5(req) M6-5-6(req) MThe loop-counter shall be modified by one of: –, ++, -=n, or +=n;where n remains constant for the duration of the loop.A loop-control-variable other than the loop-counter shall not be modifiedwithin condition or expression.A loop-control-variable other than the loop-counter which is modified instatement shall have type bool.Copyright © Quantum Leaps, LLC. All Rights Reserved.20 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.31 Jump statementsRule No.PC-LintQP/C++QPapp.Description6-6-1(req) M (1) Any label referenced by a goto statement shall be declared in thesame block, or in a block enclosing the goto statement.6-6-2(req) A (1) The goto statement shall jump to a label declared later in the samefunction body.6-6-3(req) A (2) The continue statement shall only be used within a well-formed forloop.6-6-4(req) A (3) For any iteration statement there shall be no more than one break orgoto statement used for loop termination.6-6-5(req) A(4) A function shall have a single point of exit at the end of the function.(1)QP/C++ source code does not use goto.(2)QP/C++ source code does not use continue.(3)QP/C++ source code does not use break for loop termination.(4)The published examples of state handler function with QP/C++ deviate from MISRA-C++ rule 6-6-5.However, a fully compliant implementation is also possible and is described in Section 6.4.3.32 SpecifiersRule No.PC-LintQP/C++QPapp.Description7-1-1(req) 5.11 A variable which is not modified shall be const qualified.7-1-2(req) AA pointer or reference parameter in a function shall be declared aspointer to const or reference to const if the corresponding object is notmodified.3.33 Enumeration declarationsRule No.PC-LintQP/C++7-2-1(req) AQPapp.DescriptionAn expression with enum underlying type shall only have valuescorresponding to the enumerators of the enumeration.Copyright © Quantum Leaps, LLC. All Rights Reserved.21 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.34 NamespacesRule No.PC-LintQP/C++QPapp.Description7-3-1(req) A (1) The global namespace shall only contain main, namespacedeclarations and extern "C" declarations.7-3-2(req) AThe identifier main shall not be used for a function other than the globalfunction main.7-3-3(req) A There shall be no unnamed namespaces in header files.7-3-4(req) A using-directives shall not be used.7-3-5(req) MMultiple declarations for an identifier in the same namespace shall notstraddle a using-declaration for that identifier.using-directives and using-declarations (excluding class scope or7-3-6(req) Afunction scope using-declarations) shall not be used in header files.(1)QP/C++ source code can be configured to place all declarations and definitions in the QP::namespace. This is the recommended setting for MIRSA-C++:2008 compliance.3.35 The asm declarationRule No.PC-LintQP/C++QPapp.Description7-4-1(doc) M (1) All usage of assembler shall be documented.7-4-2(req) AAssembler instructions shall only be introduced using the asmdeclaration.7-4-3(req) M (1) Assembly language shall be encapsulated and isolated.(1)QP/C++ encapsulates and isolates potential use of assembler language in the macrosQF_INT_ENABLE(), QF_INT_DISABLE(), QF_CRIT_ENTRY(), QF_CRIT_EXIT(), QK_ISR_ENTRY(), andQK_ISR_EXIT()3.36 Linkage specificationsRule No.PC-LintQP/C++QPapp.Description7-5-1(req) A7-5-2(req) A7-5-3(req) AA function shall not return a reference or a pointer to an automaticvariable (including parameters), defined within the function.The address of an object with automatic storage shall not be assignedto another object that may persist after the first object has ceased toexist.A function shall not return a reference or a pointer to a parameter that ispassed by reference or const reference.7-5-4(adv) A Functions should not call themselves, either directly or indirectly.Copyright © Quantum Leaps, LLC. All Rights Reserved.22 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.37 Declarations — GeneralRule No.PC-LintQP/C++QPapp.Description8-0-1(req) AAn init-declarator-list or a member-declarator-list shall consist of asingle init-declarator or member-declarator respectively.3.38 Meaning of declarationsRule No.PC-LintQP/C++QPapp.Description8-3-1(req) AParameters in an overriding virtual function shall either use the samedefault arguments as the function they override, or else shall notspecify any default arguments.3.39 Function definitionsRule No.PC-LintQP/C++QPapp.Description8-4-1(req) A Functions shall not be defined using the ellipsis notation.8-4-2(req) A8-4-3(req) MThe identifiers used for the parameters in a re-declaration of a functionshall be identical to those in the declaration.All exit paths from a function with non-void return type shall have anexplicit return statement with an expression.8-4-4(req) (1) MA function identifier shall either be used to call a function or it shall bepreceded by &.(1)PC-Lint reports the recommended use of the & operator on function names as the error 546 (suspicioususe of &). This is actually contrary to the MISRA-C++:2008 guidelines, so the error 546 is suppressed inthe lib-qpcpp.lnt option file.3.40 Declarators — InitializersRule No.PC-LintQP/C++QPapp.Description8-5-1(req) 5.12 All variables shall have a defined value before they are used.8-5-2(req) ABraces shall be used to indicate and match the structure in the nonzeroinitialization of arrays and structures.8-5-3(req) MIn an enumerator list, the = construct shall not be used to explicitlyinitialize members others than the first, unless all items are explicitlyinitialized.(1)PC-Lint includes in this rule also checks of the constructor initializer lists. QP/C++ deviates from thisrule only in the constructor initializer lists for QEvt and QActive.Copyright © Quantum Leaps, LLC. All Rights Reserved.23 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.41 Member functionsRule No.PC-LintQP/C++9-3-1(req) AQPapp.Descriptionconst member functions shall not return non-const pointers orreferences to class-data.9-3-2(req) A Member functions shall not return non-const handles to class-data.9-3-3(req) AIf a member function can be made static then it shall be madestatic, otherwise if it can be made const then it shall be made const.3.42 UnionsRule No.PC-LintQP/C++QPapp.9-5-1(req) 5.13 (1) Unions shall not be used.Description(1)QP/C++ deviates from this rule in the QMAttr type and in QS functions QS::f32 and QS::f64 in theQ_SPY configuration3.43 Bit-fields (1)Rule No.PC-LintQP/C++9-6-1(doc) M9-6-2(req) AQPapp.DescriptionWhen the absolute positioning of bits representing a bit-field is required,then the behavior and packing of bit-fields shall be documented.Bit-fields shall be either bool type or an explicitly unsigned or signedintegral type.9-6-3(req) A Bit-fields shall not have enum type.Named bit-fields with signed integer type shall have a length of more9-6-4(req) Athan one bit.(1)QP/C++ does not use bit fields at all.3.44 Multiple base classes (1)Rule No.PC-LintQP/C++QPapp.Description10-1-1(adv) A Classes should not be derived from virtual bases.10-1-2(req) MA base class shall only be declared virtual if it is used in a diamondhierarchy.An accessible base class shall not be both virtual and non-virtual in the10-1-3(req) Asame hierarchy.(1)QP/C++ does not use virtual base classes at all.Copyright © Quantum Leaps, LLC. All Rights Reserved.24 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.45 Member name lookupRule No.PC-LintQP/C++QPapp.Description10-2-1(adv) M (1) All accessible entity names within a multiple inheritance hierarchyshould be unique.(1)QP/C++ does not use multiple inheritance at all.3.46 Virtual Functions (1)Rule No.PC-LintQP/C++QPapp.Description10-3-1(req) M10-3-2(req) AThere shall be no more than one definition of each virtual function oneach path through the inheritance hierarchy.Each overriding virtual function shall be declared with the virtualkeyword.A virtual function shall only be overridden by a pure virtual function if it10-3-3(req) Mis itself declared as pure virtual.(1)Except for virtual destructors in QFsm and QHsm base classes, QP/C++ does not use virtual functions.3.47 ConstructorsRule No.PC-LintQP/C++QPapp.Description12-1-1(req) A12-1-2(adv) AAn object’s dynamic type shall not be used from the body of itsconstructor or destructor.All constructors of a class should explicitly call a constructor for all of itsimmediate base classes and all virtual base classes.12-1-3(req) M (1) All constructors that are callable with a single argument of fundamentaltype shall be declared explicit.(1)The QP/C++ code does not contain any constructors with single argument of fundamental type.3.48 Copying class objectsRule No.PC-LintQP/C++QPapp.Description12-8-1(req) A12-8-2(req) AA copy constructor shall only initialize its base classes and the nonstaticmembers of the class of which it is a member.The copy assignment operator shall be declared protected or private inan abstract class.Copyright © Quantum Leaps, LLC. All Rights Reserved.25 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.49 Template declarations (1)Rule No.PC-LintQP/C++QPapp.Description14-5-1(req) A14-5-2(req) AA non-member generic function shall only be declared in a namespacethat is not an associated namespace.A copy constructor shall be declared when there is a templateconstructor with a single parameter that is a generic parameter.A copy assignment operator shall be declared when there is a template14-5-3(req) Aassignment operator with a parameter that is a generic parameter.(1)QP/C++ code does not use templates anywhere in the code.3.50 Name resolution (1)Rule No.PC-LintQP/C++QPapp.Description14-6-1(req) AIn a class template with a dependent base, any name that may befound in that dependent base shall be referred to using a qualified-id orthis->The function chosen by overload resolution shall resolve to a function14-6-2(req) Adeclared previously in the translation unit.(1)QP/C++ code does not use templates anywhere in the code.3.51 Template instantiation and specialization (1)Rule No.PC-LintQP/C++QPapp.Description14-7-1(req) A14-7-2(req) MAll class templates, function templates, class template memberfunctions and class template static members shall be instantiated atleast once.For any given template specialization, an explicit instantiation of thetemplate with the template-arguments used in the specialization shallnot render the program ill-formed.All partial and explicit specializations for a template shall be declared in14-7-3(req) Athe same file as the declaration of their primary template.(1)QP/C++ code does not use templates anywhere in the code.3.52 Function template specialization (1)Rule No.PC-LintQP/C++QPapp.Description14-8-1(req) A Overloaded function templates shall not be explicitly specialized.The viable function set for a function call should either contain no14-8-2(adv) Afunction specializations, or only contain function specializations.(1)QP/C++ code does not use templates anywhere in the code.Copyright © Quantum Leaps, LLC. All Rights Reserved.26 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.53 Exception handling — General (1)Rule No.PC-LintQP/C++QPapp.Description15-0-1(doc) M Exceptions shall only be used for error handling.15-0-2(adv) A An exception object should not have pointer type.15-0-3(req) AControl shall not be transferred into a try or catch block using a gotoor a switch statement.(1)QP/C++ code does not throw or catch exceptions anywhere in the code.3.54 Throwing an exceptionRule No.PC-LintQP/C++15-1-1(req) MQPapp.DescriptionThe assignment-expression of a throw statement shall not itself causean exception to be thrown.15-1-2(req) A NULL shall not be thrown explicitly.15-1-3(req) AAn empty throw (throw;) shall only be used in the compoundstatementof a catch handler.3.55 Handling an exceptionRule No.PC-LintQP/C++15-3-1(req) A15-3-2(adv) A15-3-3(req) M15-3-4(req)QPapp.DescriptionExceptions shall be raised only after start-up and before termination ofthe program.There should be at least one exception handler to catch all otherwiseunhandled exceptionsHandlers of a function-try-block implementation of a class constructoror destructor shall not reference non-static members from this class orits bases.Each exception explicitly thrown in the code shall have a handler of acompatible type in all call paths that could lead to that point.15-3-5(req) A class type exception shall always be caught by reference.15-3-6(req)15-3-7(req)Where multiple handlers are provided in a single try-catch statement orfunction-try-block for a derived class and some or all of its bases, thehandlers shall be ordered most-derived to base class.Where multiple handlers are provided in a single try-catch statement orfunction-try-block, any ellipsis (catch-all) handler shall occur last.Copyright © Quantum Leaps, LLC. All Rights Reserved.27 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.56 Exception specificationRule No.PC-LintQP/C++15-4-1(req) AQPapp.DescriptionIf a function is declared with an exception-specification, then alldeclarations of the same function (in other translation units) shall bedeclared with the same set of type-ids.3.57 Exception handling — Special functionsRule No.PC-LintQP/C++QPapp.Description15-5-1(req) A A class destructor shall not exit with an exception.15-5-2(req) AWhere a function’s declaration includes an exception-specification, thefunction shall only be capable of throwing exceptions of the indicatedtype(s).15-5-3(req) M The terminate() function shall not be called implicitly.3.58 Processing directives — GeneralRule No.PC-LintQP/C++16-0-1(req) A16-0-2(adv) AQPapp.16-0-3(req) M #undef shall not be used.Description#include directives in a file shall only be preceeded by otherpreprocessor directives or comments.Macros shall only be #define’d or #undef’d in the globalnamespace.16-0-4(req) 5.14 Function-like macros shall not be defined.16-0-5(req) A16-0-6(req) A16-0-7(req) A16-0-8(req) AArguments to a function-like macro shall not contain tokens that looklike preprocessing directives.In the definition of a function-like macro, each instance of a parametershall be enclosed in parentheses, unless it is used as the operand of #or ##.Undefined macro identifiers shall not be used in #if and #elifpreprocessor directives, except as operands to the defined operator.If the # token appears as the first token on aline, then it shall beimmediately followed by a preprocessing token.Copyright © Quantum Leaps, LLC. All Rights Reserved.28 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.59 Conditional inclusionRule No.PC-LintQP/C++16-1-1(req) A16-1-2(req) AQPapp.DescriptionThe defined preprocessor operator shall only be used in one of thetwo standard forms.All #else, #elif and #endif preprocessor directives shall reside in thesame file as #if or #ifdef directive to which they are related.3.60 Source file inclusionRule No.PC-LintQP/C++QPapp.Description16-2-1(req) 5.15 Preprocessor shall only be used for file inclusion and include guards.16-2-2(req) 5.15C++ macros shall only be used for: include guards, type qualifiers, orstorage class specifiers.16-2-3(req) A Include guards shall be provided.16-2-4(req) A The ', ", /* or // characters shall not occur in a header file name.16-2-5(adv) A The \ character should not occur in a header file name.16-2-6(req) AThe #include directive shall be followed by either a or"filename" sequence.3.61 Macro replacementRule No.PC-LintQP/C++16-3-1(req) AQPapp.DescriptionThere shall be at most one occurrence of the # or ## operators in asingle macro definition.16-3-2(adv) 5.16 (1) . (1) The # and ## operators should not be used.(1)QP/C++ code uses a single ## operator in the Q_NEW() macro and only when constructors for QEvtsare allowed (Q_EVT_CTR macro is defined). Additionally, the “dictionary” QS macros use a single #operator.3.62 Pragma directiveRule No.PC-LintQP/C++QPapp.Description16-6-1(doc) M All uses of the #pragma directive shall be documented.Copyright © Quantum Leaps, LLC. All Rights Reserved.29 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.63 Library introduction — GeneralRule No.PC-LintQP/C++QPapp.Description17-0-1(req) A(1) Reserved identifiers, macros and functions in the standard library shallnot be defined, redefined or undefined.17-0-2(req) A(1) The names of standard library macros and objects shall not be reused.17-0-3(req) M(1) The names of standard library functions shall not be overridden.17-0-4(doc) A(1) All library code shall conform to MISRA C++.17-0-5(req) A(1) The setjmp macro and the longjmp function shall not be used.(1)Requires analysis of the complete application source code, including all libraries3.64 Language support library — General (1)Rule No.PC-LintQP/C++QPapp.18-0-1(req) A The C library shall not be used.18-0-2(req) A18-0-3(req) ADescriptionThe library functions atof, atoi and atol from library shall not be used.The library functions abort, exit, getenv and system from library shall not be used.18-0-4(req) A The time handling functions of library shall not be used.18-0-5(req) A The unbounded functions of library shall not be used.(1)QP/C++ code does not rely in any way on any standard C or C++ libraries. The stdint.h header fileused in QP/C++ does not require any code to be pulled from the standard libraries.3.65 Language support library — Implementation propertiesRule No.PC-LintQP/C++QPapp.Description18-2-1(req) A The macro offsetof shall not be used.3.66 Language support library — Dynamic memory managementRule No.PC-LintQP/C++QPapp.Description18-4-1(req) A Dynamic heap memory allocation shall not be used.Copyright © Quantum Leaps, LLC. All Rights Reserved.30 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp3.67 Language support library — Other runtime supportRule No.PC-LintQP/C++QPapp.Description18-7-1(req) A The signal handling facilities of shall not be used.3.68 Diagnostics library — Error numbersRule No.PC-LintQP/C++QPapp.Description19-3-1(req) A The error indicator errno shall not be used.3.69 Input/Output library — GeneralRule No.PC-LintQP/C++QPapp.Description27-0-1(req) A The stream input/output library shall not be used.Copyright © Quantum Leaps, LLC. All Rights Reserved.31 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp4 Beyond MISRA: Compliance with Additional Rules andStandards4.1 Strong Type CheckingThe philosophy of the C++ language is to assume that the programmers know what they are doing, whichcan mean that if errors are made they are allowed to pass unnoticed by the language. An area in whichC++ is particularly weak in this respect is that of “type checking”. C++ compilers will not object, forexample, if the programmer tries to store a floating point number in an integer that they are using torepresent a true/false value. Most such mismatches are simply forced to become compatible. If C++ ispresented with a square peg and a round hole it doesn't complain, but makes them fit!PC-Lint has an advanced strong type checking capabilities (see Chapter 9 in the PC-Lint Manual [PC-Lint 08]), which includes sophisticated dimensional analysis of the types resulting from combining othertypes (e.g., velocity_miles_per_hour = distance_miles / time_hours). The strong type checking isactivated in PC-Lint with the -strong(AJX) option.NOTE: The strong type checking of PC-Lint takes the static analysis to the next level beyond MISRA-C++, because it can turn C++ into a truly strongly-typed language.However, a software system can become “strongly-typed” only if it is built from components that are also“strongly-typed”. Fortunately, the QP/C++ framework is “strongly typed”, meaning that is passescleanly the PC-Lint analysis with the -strong(AJX) option activated. This is an immense benefit forQP/C++ users, because it allows the application-level code to take advantage of the strong type checking.4.2 Quantum Leaps C/C++ Coding StandardAlthough intentionally not addressed by the MISRA-C++:2008 guidelines, the use of a consistent codingstyle is a very important aspect of developing safety-related code. The QP/C++ code strictly follows to theQuantum Leaps C/C++ Coding Standard [QL-Code 11].Copyright © Quantum Leaps, LLC. All Rights Reserved.32 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp5 Deviation Procedures for QP/C++ Source CodeThis section documents deviations from MISRA-C++:2008 rules in the QP/C++ source code.5.1 Rule 0-1-1(req) and 0-1-2(req)A project shall not contain unreachable code.A project shall not contain infeasible paths.Deviation from these rules occurs only in the QS software tracing instrumentation and is related to QSfilters. When QS tracing is disabled, certain QS trace records might look like unreachable code orinfeasible paths (e.g., if (false) ...).5.2 Rule 0-1-11(req)There shall be no unused parameters (named or unnamed) in non-virtual functions.Deviation from this rule occurs in the standard “vanilla” and QK ports of QP/C++ (and perhaps in otherports that do not use the per-task stacks). For the sake of wide-range portability, the signature of thefunctions QActive::start() must include the stack memory and stack size, but these parameters mightnot be actually used in all QP/C++ ports.5.3 Rule 3-9-3(req)The underlying bit representations of floating-point values shall not be used.Deviation from this rule occurs only in the QS software tracing instrumentation (not in production code)and is related to serialization of floating point numbers. The deviation is allowed only in the context of thefunctions QS::f32() and QS::f64().5.4 Rule 5-0-15(req)Array indexing shall be the only allowed form of pointer arithmetic.Deviation from this rule is related to the general policy of the QP/C++ framework with respect to memoryallocation. In QP/C++, all memory (e.g., memory pools or event queue buffers) is pre-allocated by theapplication code and then passed as pointer and size of the memory to the framework. Subsequently, thememory is accessed using array indexing, but from the original base pointer, not from a true array—hence the deviation from rule 5-0-15.The deviation form rule 5-0-15 is encapsulated in the QP/C++ internal macro QF_PTR_AT_(), and this isthe only context allowed to deviate per this procedure.5.5 Rule 5-0-18(req)>, >=,

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp5.6 Rule 5-2-4(req)C-style casts (other than void casts) and functional notation casts (other than explicit constructorcalls) shall not be used.Deviation from this rule occurs only in the QP assertions. For practical reasons, the qassert.h headerfile is designed to be useful both in C++ and C modules, as many embedded projects use bothlanguages. The strict use of C++ style casts would preclude using assertions in C modules, which coulddiscourage programmers from using QP assertions everywhere in the code. The deviation from rule 5-2-4should be limited to QP assertions.5.7 Rule 5-2-5(req)A cast shall not remove any const or volatile qualification from the type of a pointer or reference.QP/C++ code deviates from this rule only in the internal macros QF_EVT_REF_CTR_INC_,QF_EVT_REF_CTR_DEC_, and QF_EPOOL_PUT_, where the const qualification needs to be occasionallydiscarded. The discarding of const is always preceded by a check that a given event is indeed dynamic(by testing the QEvt.poolId_ member). Deviation from this rule is considered a better tradeoff for safetyand design correctness than not using the const qualification for events at all.5.8 Rule 5-2-7(req)An object with integer type or pointer to void type shall not be converted to an object with pointertype.QP/C++ code deviates from this rule in the internal macro QF_EPOOL_GET_, where a generic pointer to amemory block is cast to a specific object type. This sort of cast is inevitable in any memory allocator, butis strictly encapsulated inside the QF_EPOOL_GET_ macro.5.9 Rule 5-2-9(adv)A cast should not convert a pointer type to an integral type.Deviation from this rule occurs only in the QS software tracing instrumentation (not in production code).The QS code needs to output pointers to functions and pointers to objects by means of the macrosQS_FUN_, QS_OBJ_, respectively. The deviation is allowed only in the context of these macros.5.10 Rule 5-2-10(adv)The increment (++) and decrement (--) operators should not be mixed with other operators in anexpressionDeviation from this rule occurs only in the QS software tracing macro QS_TEC_ (not in production code).5.11 Rule 7-1-1(req)A variable which is not modified shall be const qualified.Deviation from this rule might occur in some QP/C++ ports, which don't use all the parameters of theQActive::start() method. For example, QP/C++ ports to the built-in “Vanilla” and QK kernels don'tneed the per-task stack and re-use the stack and stack-size parameters for different purposes. In thesecases the stack and/or the stack-size is not modified and could be const-qualified, but this would interferewith the portability of the QP/C++ framework.Copyright © Quantum Leaps, LLC. All Rights Reserved.34 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp5.12 Rule 8-5-1(req)All variables shall have a defined value before they are used.The QP/C++ code complies with this rule everywhere, except the compiler-initialization lists for QActiveand QEvt classes, which PC-Lint includes in checking this rule.The constructor of QActive intentionally does not initialize the m_prio, m_eQueue, m_thread, andm_osObject members, because in QP/C++ the initialization of active objects is a two-stage process (withthe second stage of initialization happening in the top-most initial transition) to give the applicationdesigner the necessary control over the timeline of initialization. Also, some members of the QActivebase class exist only in the certain QP/C++ ports and don't exist in others.5.13 Rule 9-5-1(req)Unions shall not be used.For production code, deviation from this rule occurs in the QEP component in the data type QMAttr,which used to specify the private state machine attribute in the QMsm base class. The use of a union in thiscase is strictly encapsulated inside the QEP event processor code and is never accessed in theapplication-level code. The justification of deviating from the rule 9-5-1 are significant savings in RAM forevery state machine in the system as well as backwards-compatibility with the classes QHsm and QFsm.Deviation from this rule occurs also in the QS software tracing instrumentation (not in production code)and is related to serialization of floating point numbers. The deviation is allowed only in the context of thefunctions QS::f32() and QS::f64().5.14 Rule 16-0-4(req), 16-2-1(req), and 16-2-2(req)Function-like macros shall not be defined.QP/C++ uses function-like macros in situations that an (inline) function cannot handle. For example, theQS software tracing or assertions need to be configurable to be activated or deactivated at compile-time(without actually changing the source code). Finally, function-like macros are used to encapsulate thevery specific contexts of deviations from the MISRA rules, such as specific type casts. All function-likemacros deviating from the rule 16-0-4 are listed explicitly in the option files, so any other macros violatingthe rule will be reported.5.15 Rule 16-2-1(req) and 16-2-2(req)16-2-1: Preprocessor shall only be used for file inclusion and include guards.16-2-2: C++ macros shall only be used for: include guards, type qualifiers, or storage classspecifiers.A framework has much stronger requirements for configurability and portability than a specific application.The QP/C++ achieves the high degree and ease of configurability through the concept of the PlatformAbstraction Layer (PAL). The PAL, however, derives its portability from the use of preprocessor macros.For example, the QP/C++ ports must be able to configure the desired size of the event signal or themaximum number of active objects in the system. This information then determines the most optimal datastructures and algorithms to use. This is not achievable through inline functions. Also, preprocessormacros are used to encapsulate the very specific contexts of deviations from the MISRA rules, such asspecific type casts. All macros deviating from the rules 16-2-1 and 16-2-2 are listed explicitly in the optionfiles, so any other macros violating the rule will be reported.Copyright © Quantum Leaps, LLC. All Rights Reserved.35 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp5.16 Rule 16-3-2(adv)The # and ## operators should not be used.The QP/C++ source code uses the ## operator in the Q_NEW() macro, in which case, the Q_NEW() macromust take the variable number of arguments for the specific QEvt-subclass constructor (variadic macro).In the QS software tracing configuration, the QS “dictionary” records use a single # operator.6 Deviation Procedures for Application-Level CodeThis section documents deviations from MISRA-C++:2008 rules in the application-level code, which arecaused by the QP/C++ framework design or implementation. This section also describes workarounds toavoid some deviations.6.1 Rule 5-2-6(req)A cast shall not convert a pointer to a function to any other pointer type, including a pointer tofunction type.The QP/C++ applications deviate from rule 5-2-6, because the state-handler functions signatures in thederived subclasses of QHsm or QFsm are not exactly identical with the state-handler pointer-to-functionStateHandler. The deviation from rule 5-2-6 is encapsulated in the macro Q_STATE_CAST(), which isdefined as follows (file qep.h):#define Q_STATE_CAST(handler_) (reinterpret_cast(handler_))In the QP/C++ applications, the macro Q_STATE_CAST() is used to cast the initial pseudo-state-handler inthe constructor, like this:Philo::Philo(): QP::QActive(Q_STATE_CAST(&Philo::initial)),m_timeEvt(TIMEOUT_SIG){}The need to deviate from the rule 5-2-6 is a consequence of using function pointers in conjunction withclass inheritance, which are both fundamental to the QP/C++ framework. This, very particular, deviationfrom rule 5-2-6 is safe and is allowed only in the context of state-handler functions, which are related.Additionally, macros Q_TRAN() and Q_SUPER() also use the macro Q_STATE_CAST(), so they tooindirectly deviate from the rule 5-2-6.6.2 Rule 5-2-7(req)An object with pointer type shall not be converted to an unrelated pointer type, either directly orindirectly.The QP/C++ applications deviate from rule 5-2-7 because of downcasting the generic event pointer (QEvtconst *) to the specific event in the state machine code. The QP/C++ framework encapsulates thisdeviation in the macro Q_EVENT_CAST(). The code snippet below shows a use case. Please note that themacro Q_EVENT_CAST() does not cast the const away, so writing to the event pointer is not allowed.case EAT_SIG: {if (Q_EVENT_CAST(TableEvt)->philoNum == PHILO_ID(me)) . . .Copyright © Quantum Leaps, LLC. All Rights Reserved.36 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp6.3 Rule 5-2-8(req)An object with integer type or pointer to void type shall not be converted to an object with pointertype.The QP/C++ applications might deviate from rule 5-2-8 when they need to access specific hard-codedhardware addresses directly. The QP/C++ framework encapsulates this deviation in the macroQ_UINT2PTR_CAST(). The following code snippet provides a use case of this macro:#define QK_ISR_EXIT() . . . \*Q_UINT2PTR_CAST(uint32_t, 0xE000ED04U) = \static_cast(0x10000000U); \6.4 Rule 6-4-3(req), 6-4-5(req), and 6-4-6(req)6-4-3(req): A switch statement shall be a well-formed switch statement.6-4-5(req): An unconditional throw or break statement shall terminate every non-empty switchclause.6-4-6(req): The final clause of a switch statement shall be the default clause.The traditional way of implementing state-handler functions in QP/C++, as described in the book“Practical UML Statecharts” [PSiCC2 08] deviates from the rules 6-4-3, 6-4-5, and 6-4-6. However, it isalso possible to avoid all these deviations, in exchange for a slight change in the UML semantics of guardprocessing, which will become clearer after describing the implementation.The MISRA-compliant state handler implementation is used in the DPP examples with lint described inSection 8. The following Listing 4 shows an example of MISRA-compliant state handler function. Theexplanation section immediately following the listing highlights the important points.NOTE: Starting from the QM version 2.2.00, the QM modeling tool generates MSRA-C++ compliantcode structure shown in Listing 4.Listing 4: MISRA-C++ compliant state handler implementationQP::QState Philo::hungry(Philo * const me, QP::QEvt const * const e) {(1) QP::QState status;switch (e->sig) {case Q_ENTRY_SIG: {AO_Table->POST(pe, Q_NEW(TableEvt, HUNGRY_SIG, PHILO_ID(me)));(2) status = Q_HANDLED();(3) break;}case EAT_SIG: {(4) if (Q_EVENT_CAST(TableEvt)->philoNum == PHILO_ID(me)) {(5) status = Q_TRAN(&Philo::eating);}Copyright © Quantum Leaps, LLC. All Rights Reserved.37 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp(6) else {(7) status = Q_UNHANDLED();}(8) break;}(9) default: {(10) status = Q_SUPER(&QHsm::top);(11) break;}}(12) return status;}(1) The automatic variable status will store the status of the processing to return. Please note that thestatus variable is not initialized.NOTE: The status variable is not initialized intentionally, to catch any path through the code thatwould not set the value explicitly. The vast majority of compilers (including, of course PC-Lint) raise awarning about an uninitialized variable to alert of the problem. However, it is highly recommended totest each particular compiler for the ability to report this problem.(2) The return value is set to Q_HANDLED() macro. This tells the QEP event processor that the entryaction has been handled.(3) According to the recommended MISRA-C switch statement structure, the case is terminated with abreak(4) The guard condition is coded as usual with an if-statement. Please note the use of theQ_EVENT_CAST() macro to downcast the generic event pointer to TableEvt class.(5) When the guard condition in the if-statement evaluates to TRUE, the return value is set toQ_TRAN() macro. This macro tells the QEP event processor that the event has been handled andthat the transition to state Philo::eating needs to be taken.Figure 1: A choice point without an explicit [else] branchentry /hungryEAT[((TableEvt const *)e)->philoNum== PHILO_ID(me)] /BSP_busyDelay();(6,7) When the guard condition evaluates to FALSE, and the state model does not explicitly prescribehow to handle this situation (see Figure 1), the code should have an implicit else branch, in whichthe return value is set from the macro Q_UNHANDLED(). This specific return value will cause the QEPevent processor to propagate the event to the superstate, which is exactly what the UMLspecification prescribes in this case.Copyright © Quantum Leaps, LLC. All Rights Reserved.38 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qpNOTE: The Q_UNHANDLED() macro has been introduced in QP version 4.5.01 exactly for MISRAcompliance. The QM graphical modeling tool generates MISRA-compliant code described in thissection starting from the version 2.2.00.(8) According to the recommended MISRA-C++ switch statement structure, the case is terminatedwith a break(9) According to the recommended switch structure, the default-clause is the final clause.(10) Inside the default-clause, the return value is set to Q_SUPER() macro. This tells the QEP eventprocessor that QHsm::top is the superstate of this state.(11) According to the recommended MISRA-C switch statement structure, the default-clause isterminated with a break(12) In compliance with MISRA-C rules 14.7 and 16.8, the function terminates with the single returnstatement.7 SummaryThe QP/C++ framework complies with most of the MISRA-C++:2008 rules and all remaining deviationsare carefully insulated and encapsulated into very specific contexts. The framework goes even beyondMISRA, by complying with string type checking and a consistent, documented coding standard.QP/C++ comes with extensive support for automatic rule checking by means of PC-Lint, which isdesigned not just for proving compliance of the QP/C++ framework code, but more importantly, to aid inchecking compliance of the application-level code. Any organization engaged in designing safety-relatedembedded software could benefit from the unprecedented quality infrastructure built around the QP/C++framework.Copyright © Quantum Leaps, LLC. All Rights Reserved.39 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp8 Related Documents and ReferencesDocumentLocation[MISRA-C++:2008] MISRA-C++:2008 Guidelines Available for purchase from MISRA websitefor the Use of the C++ language in Critical http://www.misra.org.ukSystems, MISRA, June 2008,ISBN: 978-1-906400-03-3 paperbackISBN: 978-1-906400-04-0 PDF[ISO C++ 03] ISO/IEC 14882:2003, The C++ www.iso.org/iso/catalogue_detail.htm?csnumber=38110Standard Incorporating Technical Corrogendum1, International Organization for Standardization,2003.[PC-Lint 08] “Reference Manual for PClint/FlexeLint:A Diagnostic Facility for C and C++”, Software Version 9.00 and Later, GimpelSoftware, September, 2008[PC-Lint-MISRA-C++:2008] PC-Lint/FlexeLintSupport for MISRA C++,[QL-Code 11] “Application Note: C/C++ CodingStandard”, Quantum Leaps, LLC, 2011[QL AN-DPP 08] “Application Note: DiningPhilosopher Problem Application”, QuantumLeaps, LLC, 2008Bundled with PC-Lint from Gimpelhttp://www.gimpel.comAvailable from Gimpel after requesthttp://www.state-machine.com/resources/AN_QL_Coding_Standard.pdfhttp://www.state-machine.com/resources/AN_DPP.pdfCopyright © Quantum Leaps, LLC. All Rights Reserved.40 of 41

Application NoteQP/C++ MISRA-C++:2008 Compliance Matrixstate-machine.com/qp9 Contact InformationQuantum Leaps, LLC103 Cobble Ridge DriveChapel Hill, NC 27516USA+1 866 450 LEAP (toll free, USA only)+1 919 869-2998 (FAX)e-mail: info@quantum-leaps.comWEB : http://www.quantum-leaps.comhttp://www.state-machine.com“Practical UMLStatecharts in C/C++,Second Edition: EventDriven Programming forEmbedded Systems”,by Miro Samek,Newnes, 2008Legal DisclaimersInformation in this document is believed to be accurate and reliable. However, Quantum Leaps does not give anyrepresentations or warranties, expressed or implied, as to the accuracy or completeness of such information andshall have no liability for the consequences of use of such information.Quantum Leaps reserves the right to make changes to information published in this document, including withoutlimitation specifications and product descriptions, at any time and without notice. This document supersedes andreplaces all information supplied prior to the publication hereof.All designated trademarks are the property of their respective owners.Copyright © Quantum Leaps, LLC. All Rights Reserved.41 of 41