MISRA C++:2008 Guidelines for the Use of the C++ Language in Critical Systems

The Motor Industry Software Reliability Association

MISRA C++:2008 Guidelines for the use of the C++ language in critical systems

Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1

June 2008 First published June 2008

MIRA Limited Watling Street Nuneaton Warwickshire CV10 0TU UK www.misra-cpp.com

“MISRA”, “MISRA C” and the triangle logo are registered trademarks of MIRA Limited, held on behalf of the MISRA Consortium.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical or photocopying, recording or otherwise without the prior written permission of the Publisher.

ISBN 978-1-906400-03-3 paperback ISBN 978-1-906400-04-0 PDF

Printed by Hobbs the Printers Ltd

British Library Cataloguing in Publication Data. A catalogue record for this book is available from the British Library This copy of MISRA C++:2008 - Guidelines for the use of the C++ language in critical systems is issued to He Yulin of Insigma Rail Transport. Engineering Co. at No.9 Hangda Road, Hangzhou, Zhejiang, 310007. The file must not be altered in any way. No permission is given for distribution of this file. This includes but is not exclusively limited to making the copy available to others by email, placing it on a server for access by intra- or inter-net, or by printing and distributing hardcopies. Any such use constitutes an infringement of copyright. MISRA gives no guarantees about the accuracy of the information contained in this PDF version of the Guidelines. The published paper document should be taken as authoritative. Information is available from the MISRA web site on how to purchase printed copies of the document.

Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 The Motor Industry Software Reliability Association

MISRA C++:2008

Guidelines for the use of the C++ language in critical systems

June 2008

Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 MISRA Mission Statement: To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software.

MISRA, The Motor Industry Software Reliability Association, is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles and other embedded systems. To this end MISRA publishes documents that provide accessible information for engineers and management, and holds events to permit the exchange of experiences between practitioners. www.misra.org.uk

Disclaimer Adherence to the requirements of this document does not in itself ensure error-free robust software or guarantee portability and re-use. Compliance with the requirements of this document, or any other standard, does not of itself confer immunity from legal obligations.

ii Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Foreword

“C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.” — Bjarne Stroustrup Few could have predicted the effect that MISRA C would have within embedded systems engineering. Since its launch in 1998, it has become the dominant coding standard used for the development of critical systems with the C programming language. Given this success, the fact that C++ is now being used within critical systems (e.g. the Joint Strike Fighter, jet-engine controllers and medical systems), and that there is currently no universally accepted set of guidelines for its use in these systems, MISRA committed itself to the development of a similar set of guidelines for C++. To that end, the MISRA C++ Working Group was established towards the end of September 2005. Its objectives were to: • Produce, using techniques similar to those within MISRA C, a C++ subset suitable for use in critical systems; • Gather existing C++ guidelines from many diverse sources into a single repository; • Add new guidance so as to significantly enhance the state-of-the-art; • Establish a single, generic set of guidelines for the use of C++ in critical systems; • Produce guidelines that are understandable to the majority of programmers. The work to produce the guidelines made a rapid start, and was greatly assisted by the many in- house coding standards that were made available to the group — thanks are due to all those who contributed. These, and the guidelines available from other sources, formed a solid foundation on which to base many rules. Focus then moved on to the production of guidelines for Templates, Inheritance and Exception Handling, with these areas being specifically targeted as the existing state-of-the-art did not provide adequate coverage. The issues associated with Unnecessary Constructs were also selected for investigation. This document contains the results of these activities. The group hopes that MISRA C++ will go on to become as successful and widely-adopted as MISRA C. Finally, I would like to give my personal thanks to all of those who sat on the Working Group. I have, as always, learnt a lot from them during the development process. I just hope I have managed to put enough back into the project to repay part of the debt I owe them all.

Chris Tapp, BSc (Hons), MIEE MISRA C++ Chairman 15 April 2008

iii Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Acknowledgements

The MISRA consortium would like to thank the following individuals for their significant contribution to the writing of this document: Richard Corden Programming Research Ltd Mike Hennell LDRA Ltd Derek Jones Knowledge Software Ltd Keith Longmore Lotus Cars Ltd Clive Pygott QinetiQ Ltd Chris Tapp Keylevel Consultants Ltd

The MISRA consortium also wishes to acknowledge contributions from the following individuals during the development and review process: Dave Banham Al Grant Frank Martinez John Ridgway Martin Beeby Christopher Hall Jason Masters Iris Rödder Fergus Bolger Frank Haug Jürgen Mottok Walter Schilling Martin Bonner Stefan Heinzmann Chris Mycock Ben Smith Michael R. Bossert Robert Hooper Tadanori Nakagawa Andreas Stangl Antonio Cavallo Elmar Hufschmid Hans Odeberg Toshihiro Tajima Ian Chalinder Paul Jeary Charles Osborn David Ward Kwok Chan Josef Kollar Rob Pearce Andrew Warren Valéry Creux Albert Kreitmeyr PremAnand M Rao Andrew Watson David Crocker Fred Long Derek Reinhardt Ashley Wise Thomas M. Galla Andreas Ludwig David Reversat

iv Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Contents

1. Background...... 1 1.1 The use of C++ in critical systems...... 1 1.2 Language insecurities and the C++ language...... 1 1.2.1 The developer makes mistakes...... 1 1.2.2 The developer misunderstands the language...... 2 1.2.3 The compiler does not do what the developer expects...... 2 1.2.4 The compiler contains errors...... 2 1.2.5 Run-time errors...... 2 1.3 The use of C++ for safety-related systems...... 2 1.4 C++ standardization...... 3

2. The vision...... 4 2.1 Rationale for the production of MISRA C++...... 4 2.2 Objectives of MISRA C++...... 4

3. Scope...... 5 3.1 Base language issues...... 5 3.2 Issues not addressed...... 5 3.3 Applicability...... 5 3.4 Prerequisite knowledge...... 5 3.5 Library issues...... 5 3.6 Auto-generated code issues...... 6

4. Using MISRA C++...... 7 4.1 The software engineering context...... 7 4.2 The programming language and coding context...... 7 4.2.1 Training...... 7 4.2.2 Style guide...... 8 4.2.3 Tool selection and validation...... 8 4.2.4 Source complexity metrics...... 9 4.2.5 Test coverage...... 9 4.3 Adopting the subset...... 10 4.3.1 Compliance matrix...... 10 4.3.2 Deviation procedure...... 10 4.3.3 Formalization within quality system...... 12 4.3.4 Introducing the subset...... 12 4.4 Claiming compliance...... 12 4.5 Continuous improvement...... 12

v Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Contents (continued)

5. Introduction to the rules...... 13 5.1 Rule classification...... 13 5.1.1 Required rules...... 13 5.1.2 Advisory rules...... 13 5.1.3 Document rules...... 13 5.2 Organization of rules...... 13 5.3 Exceptions to the rules...... 13 5.4 Redundancy in the rules...... 14 5.5 Presentation of rules...... 14 5.6 Understanding the issue references...... 15 5.7 Scope of rules...... 16

6. Rules...... 17 6.0 Language independent issues...... 17 6.0.1 Unnecessary constructs...... 17 6.0.2 Storage...... 25 6.0.3 Runtime failures...... 26 6.0.4 Arithmetic...... 29 6.1 General ...... 30 6.1.0 Language...... 30 6.2 Lexical conventions...... 31 6.2.2 Character sets...... 31 6.2.3 Trigraph sequences...... 31 6.2.5 Alternative tokens...... 32 6.2.7 Comments...... 32 6.2.10 Identifiers...... 34 6.2.13 Literals...... 37 6.3 Basic concepts...... 40 6.3.1 Declarations and definitions...... 40 6.3.2 One Definition Rule...... 41 6.3.3 Declarative regions and scope...... 44 6.3.4 Name lookup...... 45 6.3.9 Types...... 46 6.4 Standard conversions...... 48 6.4.5 Integral promotions...... 48 6.4.10 Pointer conversions...... 50

vi Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Contents (continued)

6.5 Expressions...... 51 6.5.0 General...... 51 6.5.2 Postfix expressions...... 76 6.5.3 Unary expressions...... 83 6.5.8 Shift operators...... 86 6.5.14 Logical AND operator...... 86 6.5.17 Assignment operators...... 87 6.5.18 Comma operator...... 87 6.5.19 Constant expressions...... 88 6.6 Statements...... 89 6.6.2 Expression statement...... 89 6.6.3 Compound statement...... 90 6.6.4 Selection statements...... 91 6.6.5 Iteration statements...... 97 6.6.6 Jump statements...... 100 6.7 Declarations...... 104 6.7.1 Specifiers...... 104 6.7.2 Enumeration declarations...... 106 6.7.3 Namespaces...... 106 6.7.4 The asm declaration...... 111 6.7.5 Linkage specifications...... 112 6.8 Declarators...... 114 6.8.0 General...... 114 6.8.3 Meaning of declarators...... 115 6.8.4 Function definitions...... 116 6.8.5 Initializers...... 118 6.9 Classes ...... 120 6.9.3 Member functions...... 120 6.9.5 Unions...... 123 6.9.6 Bit-fields...... 123 6.10 Derived classes...... 125 6.10.1 Multiple base classes...... 125 6.10.2 Member name lookup...... 126 6.10.3 Virtual functions...... 127 6.11 Member access control...... 131 6.11.0 General...... 131

vii Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Contents (continued)

6.12 Special member functions...... 131 6.12.1 Constructors...... 131 6.12.8 Copying class objects...... 134 6.14 Templates...... 136 6.14.5 Template declarations...... 136 6.14.6 Name resolution...... 139 6.14.7 Template instantiation and specialization...... 141 6.14.8 Function template specialization...... 143 6.15 Exception handling...... 144 6.15.0 General...... 144 6.15.1 Throwing an exception...... 147 6.15.3 Handling an exception...... 150 6.15.4 Exception specifications...... 157 6.15.5 Special functions...... 157 6.16 Preprocessing directives...... 159 6.16.0 General...... 159 6.16.1 Conditional inclusion...... 163 6.16.2 Source file inclusion...... 164 6.16.3 Macro replacement...... 166 6.16.6 Pragma directive...... 167 6.17 Library introduction...... 167 6.17.0 General...... 167 6.18 Language support library...... 169 6.18.0 General...... 169 6.18.2 Implementation properties...... 171 6.18.4 Dynamic memory management...... 171 6.18.7 Other runtime support...... 172 6.19 Diagnostics library...... 172 6.19.3 Error numbers...... 172 6.27 Input/output library...... 173 6.27.0 General...... 173

7. References...... 174

Appendix A: Summary of rules...... 176

Appendix B: C++ vulnerabilities...... 190

Appendix C: Glossary...... 205

viii Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 1. Background 1. Background

1.1 The use of C++ in critical systems The C++ programming language [1] is growing in importance and use for critical systems. This is due largely to the inherent language flexibility, the extent of support and its potential for portability across a wide range of hardware. Specific reasons for its use include: • C++ gives good support for the high-speed, low-level, input/output operations, which are essential to many embedded systems. • The increased complexity of applications makes the use of a high-level language more appropriate than assembly language. • C++ compilers can generate code with similar size and RAM requirements to those of C. • C++ enables object-oriented design methods to be used. • A growth in portability requirements caused by competitive pressures to reduce hardware costs by porting software to new, and/or lower cost, processors at any stage in a project lifecycle. • A growth in the use of automatically-generated C++ code from modelling packages. • Increasing interest in open systems and hosted environments for which C++ is a possible language selection.

1.2 Language insecurities and the C++ language No programming language can guarantee that the final executable code will behave exactly as the programmer intended. There are a number of problems that can arise with any language, and these are broadly categorized below. Examples are given to illustrate insecurities in the C++ language.

1.2.1 The developer makes mistakes Developers make errors, which can be as simple as mis-typing a variable name, or might involve something more complicated such as misunderstanding an algorithm. The programming language has a bearing on this type of error. Firstly, the style and expressiveness of the language can assist or hinder the programmer in thinking clearly about the algorithm. Secondly, the language can make it easy or hard for typing mistakes to turn one valid construct into another valid (but unintended) construct. Thirdly, the compiler may or may not detect errors when they are made. Firstly, in terms of style and expressiveness C++ can be used to write well laid out, structured and expressive code. It can also be used to write perverse and extremely hard-to-understand code. Clearly the latter is not acceptable in a safety-related system. Secondly, the syntax of C++ is such that it is relatively easy to make typing mistakes that lead to perfectly valid code. For example, it is all too easy to type “=” (assignment) instead of “==” (logical comparison) and the result is nearly always valid (but wrong), while an extra semi-colon on the end of an if statement can completely change the logic of the code. Thirdly, the philosophy of C++ is to assume that the developers know what they are doing, which can mean that if errors are made they are allowed to pass unnoticed by the compiler. An area in which C++ is particularly weak (though better than C) in this respect is that of “type checking”. C++ will not object, for example, if the programmer tries to store a floating-point number in an

1 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 1. Background (continued) object of type bool. Most such mismatches are simply forced to become compatible. If C++ is presented with a square peg and a round hole it does not complain, but makes them fit!

1.2.2 The developer misunderstands the language Developers can misunderstand the effect of constructs in a language. Some languages are more open to such misunderstandings than others. There are a number of areas of the C++ language that are prone to developer-introduced errors. For example, the rules for operator precedence are well defined but complex, and it is easy for a developer to make incorrect assumptions in an expression.

1.2.3 The compiler does not do what the developer expects If a language has features that are not completely defined, or are ambiguous, then a developer can assume one thing about the meaning of a construct, while the compiler may interpret it quite differently. There are many areas of the C++ language that are not completely defined, and so behaviour may vary from one compiler to another. In some cases the behaviour can vary even within a single compiler, depending on the context. ISO/IEC 14882:2003 [1] contains numerous issues that may vary in this way. However, it does not list them in the way that the C standard does in its “Portability issues” annex. To aid in ensuring coverage of the issues and to allow traceability, they have been extracted and are shown in Appendix B.

1.2.4 The compiler contains errors A language compiler (and associated linker etc.) is itself a software tool. Compilers may not always compile code correctly. They may, for example, not comply with the language standard in certain situations, or they may simply contain “bugs”. Because there are aspects of the C++ language that are hard to understand, compiler writers have been known to misinterpret the standard and implement it incorrectly. Some areas of the language are more prone to this than others. In addition, compiler writers sometimes consciously choose to vary from the standard.

1.2.5 Run-time errors A somewhat different language issue arises with code that has compiled correctly, but due to the particular data supplied to it, causes errors during the execution of the code. Languages can build run-time checks into the executable code to detect many such errors and take appropriate action. C++ is generally poor in providing run-time checking. This is one of the reasons why the code generated by C++ tends to be small and efficient, but there is a penalty to pay in terms of detecting errors during execution. C++ compilers generally do not provide run-time checking for such common problems as arithmetic exceptions (e.g. divide by zero), overflow, validity of addresses for pointers, or array bound errors.

1.3 The use of C++ for safety-related systems It should be clear from Section 1.2 that great care needs to be exercised when using C++ within safety-related systems. Because of the kinds of issues identified above, various concerns have

2 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 1. Background (continued) been expressed about the use of C++ in safety-related systems. Certainly, it is clear that the full C++ language should not be used for programming safety-related systems. However, in its favour, C++ is mature and consequently well-analysed and tried in practice. Therefore some of its deficiencies are known and understood. Additionally, there is a large amount of tool support available commercially which can be used to statically check the C++ source code and warn the developer of the presence of many of the problematic aspects of the language. If, for practical reasons, it is necessary to use C++ on a safety-related system, then the use of the language must be constrained to avoid, as far as is practicable, those aspects of the language which do give rise to concerns. This document provides one such set of constraints (often referred to as a “language subset”). Note that assembly language is no more suitable for safety-related systems than C++ and, in some respects, is worse. Use of assembly language in safety-related systems is not recommended, and generally if it is to be used then it needs to be subject to stringent constraints.

1.4 C++ standardization The standard used for this document is the C++ programming language as defined by ISO/ IEC 14882:2003 [1].

3 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 2. The Vision 2. The vision

2.1 Rationale for the production of MISRA C++ The MISRA consortium published its Development Guidelines for Vehicle Based Software [2] in 1994, which describes the full set of measures that should be used in safety-related embedded software development for vehicle systems. In particular, the choices of language, compiler and language features to be used, in relationship with safety integrity level (SIL), are recognized to be of major importance. Section 3.2.4.3 (b) and Table 3 of the MISRA Guidelines [2] address this. One of the measures recommended is the use of a subset of a standardized language, which is already established practice in the automotive, aerospace, nuclear and defence industries. Similarly, other safety-related systems standards require subsets of programming languages in general (e.g. [12] Part 3 Table A.3) even if they do not explicitly require a subset of C++. This document therefore addresses the definition of a suitable subset of C++.

2.2 Objectives of MISRA C++ In publishing this document regarding the use of the C++ programming language, the MISRA consortium is not intending to promote the use of C++. Rather, it recognizes the already widespread use of C++, and this document seeks only to promote the safest possible use of the language. It is the hope of the MISRA consortium that this document will gain industry acceptance and that the adoption of a safer subset will become established as best practice by vehicle manufacturers, component suppliers and other industrial sectors. It should also encourage training and enhance competence in general C++ programming and in this specific subset, at both an individual level and a company level. Great emphasis is placed on the use of static checking tools to enforce compliance with the subset and it is hoped that this too will become common practice by the developers of critical systems. Although much has been written about the advantages and disadvantages of various programming languages, this information is not well-known among developers. This document makes such information readily available, which should lead to an increase in the awareness of language- choice issues among engineers and managers.

4 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 3. Scope Scope3.

3.1 Base language issues The MISRA Guidelines [2] (Table 3) and IEC 61508 [12] require that “a restricted subset of a standardized structured language” be used for critical systems. This means that the language must only be used as defined in ISO/IEC 14882:2003 [1], precluding the use of language extensions.

3.2 Issues not addressed Issues of style and code metrics are somewhat subjective. It would be hard for any group of people to agree on what was appropriate, and it would be inappropriate for MISRA to give definitive advice. It is, however, important that suitable style guidelines and appropriate metrics and limits are selected. The MISRA consortium is not in a position to recommend particular vendors or tools to enforce the restrictions adopted. The user of this document is free to choose tools, and vendors are encouraged to provide tools to enforce the rules. The onus is on the user of this document to demonstrate that their chosen tool set(s) enforces the rules adequately.

3.3 Applicability This document is designed to be applied to production code in critical systems. In terms of the implementation defined by ISO/IEC 14882:2003 [1] §1.4(7), this document is aimed at a freestanding implementation, although it also addresses library issues since standard libraries will often be supplied with an embedded compiler. The requirements of this document will not necessarily be applicable in their entirety to a hosted implementation, although many of the requirements will help create higher quality software in that context.

3.4 Prerequisite knowledge This document is not intended to be an introduction or training aid to the subjects it embraces. It is assumed that readers of this document are familiar with the ISO C++ programming language standard and associated tools, and also have access to the primary reference documents. It also assumes that developers have received appropriate training and are competent C++ language programmers.

3.5 Library issues In general, it is preferable that library code should fully satisfy the full set of MISRA C++ Rules. However, it is recognized that there are situations when this ideal cannot be achieved. In these cases it may be possible to demonstrate that there is only a small safety risk incurred if deviations are raised against these rules (e.g. Rule 0–1–5, Rule 0–1–10, Rule 14–7–1 and Rule 14–7–2). In these cases, the deviation raised shall justify that alternative strategies are in place (e.g. by identifying which library functions are intended to be used and then showing that these, and only these, have been used).

5 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 3. Scope (continued)

3.6 Auto-generated code issues It is recognized that any C++ code produced by an automatic code generation tool introduces another level of complexity into the software development process. In general, any C++ code that is produced by such a tool (either automatically by the tool or that is included by the tool but which is provided by a developer) should fully satisfy the full set of MISRA C++ rules. However, an automatic code generation tool could potentially detect MISRA C++ violations (e.g. a missing default clause in a switch statement) and supply code to ensure that the violation is eliminated. This is considered to be undesirable as the responsibility for ensuring compliance against MISRA C++ should lie with the developer (for example, could a tool always provide an appropriate default action?). MISRA AC INT [3] contains an introduction to the MISRA guidelines for the use of model-based development and automatic code generation. Note that, at the time of publication of this document, MISRA AC does not include specific guidance on the use of C++ as a target language. Additionally, if a code-generating tool is to be used, then it will be necessary to select an appropriate tool and undertake validation. Apart from suggesting that adherence to the requirements of this document may provide one criterion for assessing a tool, no further guidance is given on this matter and the reader is referred to the HSE recommendations for COTS [4]. Automatically-generated code must be treated in the same manner as manually produced code for the purpose of validation (See MISRA Guidelines [2] §3.1.3, Planning for V&V).

6 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 4. Using MISRA C++ 4. Using MISRA C++

4.1 The software engineering context Using a programming language to produce source code is only one activity in the software development process. Adhering to best practice in this one activity is of very limited value if the other commonly accepted development issues are not addressed. This is especially true for the production of safety-related systems. These issues are all addressed in the MISRA Guidelines [2] and, for example, include: • Documented development process; • Quality system capable of meeting the requirements of ISO 9001/ISO 90003/TickIT [5], [6], [7]; • Project management; • Configuration management; • Hazard analysis; • Requirements; • Design; • Coding; • Verification; • Validation. It is necessary for the software developers to justify that the whole of their development process is appropriate for the type of system they are developing. This justification will be incomplete unless a hazard analysis activity has been performed to determine the SIL allocated to the system.

4.2 The programming language and coding context Within the coding phase of the software development process, the language subset is only one aspect of many and again adhering to best practice in this aspect is of very limited value if the other issues are not addressed. Key issues, following choice of language, are: • Training; • Style guide; • Compiler selection and validation; • Checking tool validation; • Metrics; • Test coverage. All decisions made on these issues, including the reasons for those decisions, need to be documented, and appropriate records should be kept for any activities performed. Such documentation may then be included in a safety justification, if required.

4.2.1 Training In order to ensure an appropriate level of skill and competence on the part of those who produce the C++ source code, formal training should be provided for:

7 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 4. Using MISRA C++ (continued)

• The use of the C++ programming language for embedded applications; • The use of the C++ programming language for high-integrity and safety-related systems; • The use of static checking tools used to enforce adherence to the subset.

4.2.2 Style guide In addition to adopting the subset, an organization should also have an in-house style guide. This will contain guidance on issues that do not directly affect the correctness of the code but rather define a “house style” for the appearance of the source code. These issues are subjective and typically include: • Code layout and use of indenting; • Layout of braces “{ }” and block structures; • Statement complexity; • Naming conventions; • Use of comments; • Inclusion of company name, copyright notice and other standard file header information. While some of the content of the style guide may only be advisory, some may be mandatory. However the enforcement of the style guide is outside the scope of this document. For further information on style guides see [8].

4.2.3 Tool selection and validation When choosing a compiler (which should be understood to include the linker), an ISO C++ compliant compiler should be used whenever possible. Where the use of the language is reliant on an implementation-defined feature (as identified in Appendix B) then the developer must benchmark the compiler to establish that the implementation is as documented by the compiler writer. When choosing a static checking tool it is clearly desirable that the tool enforces as many of the rules in this document as possible. To this end it is essential that the tool is capable of performing checks across the whole program, and not only within a single source file. In addition, where a checking tool has capabilities to perform checks beyond those required by this document, it is recommended that the extra checks are used. The compiler and the static checking tool are generally seen as “trusted” processes. This means that there is a certain level of reliance on the output of the tools. The developer must therefore ensure that this trust is not misplaced. Ideally this should be achieved by the tool supplier running appropriate validation tests. Note that, while it is possible to use a validation suite to test a compiler for an embedded target, no formal validation scheme exists at the time of publication of this document. In addition, the tools should have been developed to a quality system capable of meeting the requirements of ISO 9001/ISO 90003 [5], [6], [7]. It should be possible for the tool supplier to show records of verification and validation activities together with change records that show a controlled development of the software. The tool supplier should have a mechanism for: • Recording faults reported by the users; • Notifying existing users of known faults; • Correcting faults in future releases.

8 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 4. Using MISRA C++ (continued)

The size of the existing user base together with an inspection of the faults reported over the previous 6 to 12 months will give an indication of the stability of the tool. It is often not possible to obtain this level of assurance from tool suppliers, and in these cases the onus is on the developer to ensure that the tools are of adequate quality. Some possible approaches the developer could adopt to gain confidence in the tools are: • Perform some form of documented validation testing; • Assess the software development process of the tool supplier; • Review the performance of the tool to date. The validation test could be performed by creating code examples to exercise the tools. For compilers this could consist of known good code from a previous application. For a static checking tool, a set of code files should be written, each breaking one rule in the subset and together covering as many as possible of the rules. For each test file the static checking tool should then find the non-conformant code. Although such tests would necessarily be limited, they would establish a basic level of tool performance. It should be noted that validation testing of the compiler must be performed for the same set of compiler options, linker options and source library versions used when compiling the product code. The use of additional static analysis checks, where available, is also recommended.

4.2.4 Source complexity metrics The use of source code complexity metrics is highly recommended. These can be used to prevent unwieldy and un-testable code being written by looking for values outside of established norms. The use of tools to collect the data is also highly recommended. Many of the static checking tools that may be used to enforce the subset also have the capability for producing metrics data. For details of possible source code metrics see “Software Metrics: A Rigorous and Practical Approach” by Fenton and Pfleeger [9] and the MISRA report on Software Metrics [10].

4.2.5 Test coverage The expected statement coverage of the software should be defined before the software is designed and written. Code should be designed and written in a manner that supports high statement coverage during testing. The term “Design For Test” (DFT) has been applied to this concept in mechanical, electrical and electronic engineering. This issue needs to be considered during the activity of writing the code, since the ability to achieve high statement coverage is an emergent property of the source code. Use of a subset, which reduces the number of implementation-dependent features and increases the rigour of module interface compatibility, can lead to software that can be integrated and tested with greater ease. Balancing the following metrics can facilitate achieving high statement coverage: • Code size; • Cyclomatic complexity. With a planned approach, the extra effort expended on software design, language use and design for test is more than offset by the reduction in the time required to achieve high statement coverage during test. See [10], [11].

9 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 4. Using MISRA C++ (continued)

4.3 Adopting the subset In order to develop code that adheres to the subset the following steps need to be taken: • Produce a compliance matrix which states how each rule is enforced; • Produce a deviation procedure; • Formalize the working practices within the quality management system.

4.3.1 Compliance matrix In order to ensure that the source code written does conform to the subset it is necessary to have measures in place that check that none of the rules have been broken. The most effective means of achieving this is to use one or more of the static checking tools that are available commercially. Where a rule cannot be checked by a tool, then a manual review will be required. In order to ensure that all the rules have been covered then a compliance matrix should be produced which lists each rule and indicates how it is to be checked. See Table 1 for an example, and see Appendix A for a summary list of the rules, which could be used to assist in generating a full compliance matrix.

Rule No. Compiler 1 Compiler 2 Checking Tool 1 Checking Tool 2 Manual Review Rule 0–1–1 warning 347 Rule 0–1–2 error 25 Rule 0–1–3 message 38 Rule 0–1–4 warning 97 Rule 0–1–5 Proc x.y Table 1: Example compliance matrix

If the developer has additional local restrictions, these too can be added to the compliance matrix. Where specific restrictions are omitted, full justifications shall be given. These justifications must be fully supported by a C++ language expert together with manager level concurrence.

4.3.2 Deviation procedure It is recognized that in some instances it may be necessary to deviate from the rules given in this document. For example, source code written to interface with the microprocessor hardware will inevitably require the use of proprietary extensions to the language. In order for the rules to have authority, it is necessary that a formal procedure be used to authorize these deviations rather than an individual programmer having discretion to deviate at will. It is expected that the procedure will be based around obtaining a sign-off for each deviation, or class of deviation. The use of a deviation must be justified on the basis of both necessity and safety. While this document does not give, nor intend to imply, any grading of importance of each of the rules, it is accepted that some provisions are more critical than others. This should be reflected in the deviation procedure, where for more serious deviations greater technical competence is required to assess the risk incurred and higher levels of management are required to accept this increased risk. Where a formal quality management system exists, the deviation procedure should be a part of this system.

10 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 4. Using MISRA C++ (continued)

Deviations may occur for a specific instance, i.e. a one-off occurrence in a single file, or for a class of circumstances, i.e. a systematic use of a particular construct in a particular circumstance, for example the use of a particular language extension to implement an input/output operation in files that handle serial communications. Strict adherence to all rules is unlikely and, in practice, deviations associated with individual situations, are admissible. There are two categories of deviation. • Project Deviation: A Project Deviation is defined as a permitted relaxation of rule requirements to be applied in specified circumstances. In practice, Project Deviations will usually be agreed at the start of a project. • Specific Deviation: A Specific Deviation will be defined for a specific instance of a rule violation in a single file and will typically be raised in response to circumstances that arise during the development process. Project deviations should be reviewed regularly and this review should be a part of the formal deviation process. Many, if not most, of the circumstances where rules need to be broken are concerned with input/ output operations. It is recommended that the software be designed such that input/output concerns are separated from the other parts of the software. As far as possible Project Deviations should then be restricted to this input/output section of the code. Code subject to Project Deviations should be clearly marked as such. The purpose of this document is to avoid problems by thinking carefully about the issues and taking all responsible measures to avoid the problems. The deviation procedure should not be used to undermine this intention. In following the rules in this document the developer is taking advantage of the effort expended by MISRA in understanding these issues. If the rules are to be deviated from, then the developer is obliged to understand the issues for themselves. All deviations, standing and specific, should be documented. For example, if it is known beforehand that it will be difficult to adhere to a rule, the software developer should submit a written Project Deviation Request and agreement with the customer should be obtained prior to programming. A Project Deviation Request should include the following: • Details of the deviation, i.e. the rule that is being violated; • Circumstances in which the need for the deviation arises; • Potential consequences which may result from the deviation; • Justification for the deviation; • A demonstration of how safety is assured. When the need for a deviation arises during or at the end of the development process, the software developer should submit a written Specific Deviation Request. A Specific Deviation Request should include the following: • Details of the deviation, i.e. the rule that is being violated; • Potential consequences which may result from the deviation; • Justification for the deviation; • A demonstration of how safety is assured. Detailed implementation of these procedures is left to the discretion of the user.

11 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 4. Using MISRA C++ (continued)

4.3.3 Formalization within quality system The use of the subset, the static checking tools and deviation procedure should be described by formal documents within the quality management system. They will then be subject to the internal and external audits associated with the quality system and this will help ensure their consistent use.

4.3.4 Introducing the subset Where an organization has an established C++ coding environment it is recommended that the requirements of this document be introduced in a progressive manner. It may take 1 to 2 years to implement all aspects of this document. Where a product contains legacy code written prior to the use of the subset, it may be impractical to rewrite it to bring it into conformance with the subset. In these circumstances the developer must decide upon a strategy for managing the introduction of the subset (for example: all new modules will be written to the subset and existing modules will be rewritten to the subset if they are subject to a change which involves more than 30% of the non-comment source lines).

4.4 Claiming compliance Compliance can only be claimed for a product and not for an organization. When claiming MISRA C++ compliance for a product, a developer is stating that evidence exists to show: • A compliance matrix has been completed which shows how compliance has been enforced; • All of the C++ code in the product is compliant with the rules of this document or subject to documented deviations; • A list of all instances of rules not being followed is being maintained, and for each instance there is an appropriately signed-off deviation; • The issues mentioned in Section 4.2 have been addressed.

4.5 Continuous improvement Adherence to the requirements of this document should only be considered as a first step in a process of continuous improvement. Users should be aware of the other literature on the subject (see references) and actively seek to improve their development process by the use of metrics.

12 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 5. Introduction to the rules 5. Introduction to the rules

This section explains the presentation of the language guidelines (the rules) given in this part of the document. It serves as an introduction to the main content of the document as presented in that section.

5.1 Rule classification Every rule is classified as “Required”, “Advisory” or “Document”, as described below. Beyond this basic classification the document does not give, nor intend to imply, any grading of importance of each of the rules. All “Required” rules should be considered to be of equal importance, as should all “Advisory”, and all “Document” rules. The omission of an item from this document does not imply that it is less important. Furthermore for projects following a safety standard that uses SIL or a similar measure of risk reduction requirements, all rules are intended to be applied regardless of the SIL claimed for the software being developed. The meanings of “Required”, “Advisory” and “Document” rules are as follows.

5.1.1 Required rules These are mandatory requirements placed on the developer. C++ code that is claimed to conform to MISRA C++ shall comply with every “Required” rule. Formal deviations must be raised where this is not the case.

5.1.2 Advisory rules These are requirements placed on the developer that should normally be followed. However they do not have the mandatory status of “Required” rules. Note that the status of “Advisory” does not mean that these items can be ignored, but that they should be followed as far as is reasonably practical. Formal deviations are not necessary for “Advisory” rules, but may be raised if it is considered appropriate.

5.1.3 Document rules These are mandatory requirements placed on the developer whenever the associated feature is used within code. Deviations are not permitted against this class of rule.

5.2 Organization of rules The rules are organized under the section numbers of ISO/IEC 14882:2003 [1]. However there is inevitably overlap, with one rule possibly being relevant to a number of topics. Where this is the case, the rule has been placed under the first relevant topic.

5.3 Exceptions to the rules Some rules contain an “Exception” section that lists one or more exceptional conditions under which the rule need not be followed. These exceptions effectively modify the headline rule.

13 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 5. Introduction to the rules (continued)

5.4 Redundancy in the rules There are a few cases within this document where a rule is given that refers to a language feature, which is banned or advised against elsewhere in the document. This is intentional. It may be that the developer chooses to use that feature, either by raising a deviation against a “Required” rule, or by choosing not to follow an “Advisory” rule. In this case, the second rule, constraining the use of that feature, becomes relevant.

5.5 Presentation of rules The individual Rules are presented in the following format: Rule () [] Where the fields are as follows: • Every rule has a unique number, consisting of three parts, aa–bb–cc. aa–bb gives the section number within ISO/IEC 14882:2003 [1] to which the rule relates. Note, because guidance is not given for every section in ISO/IEC 14882:2003 [1], the numbering of the designators aa–bb and hence of the section headings in this document are not contiguous. cc is a sequence number for rules related to the above section. Note that section 0–bb contains general guidance that does not relate to any specific area within the standard. Sections of the form aa–0 give guidance that relates to section aa of the standard, but which is not directly attributable to any particular language construct within that section. • is one of “Required”, “Advisory” or “Document”, as explained above. • is the rule itself. • indicates the section and paragraph number within ISO/IEC 14882:2003 [1] of a specific language issue which is targeted by the rule. An explanation of these issues is given below. Normative text is provided for each rule. This text gives, where appropriate, some explanation of the underlying issues being addressed by the rule, and examples of how to apply the rule. The normative text is not intended as a tutorial in the relevant language feature, as the reader is assumed to have a working knowledge of the language. Further information on the language features can be obtained by consulting the relevant section of the language standard or other C++ language reference books. Where an Issue Reference is given, then the original issue raised in ISO/IEC 14882:2003 [1] may provide additional help in understanding the rule. Within the rules and their supporting text the following font styles are used to represent C++ keywords and C++ code: C++ keywords appear in italic text

C++ code appears in a mono-spaced font, either within other text or as separate code fragments;

14 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 5. Introduction to the rules (continued)

Note that where code is quoted, the fragments may be incomplete (for example an if statement without its body). This is for the sake of brevity. In code fragments, in order to comply with Rule 3–9–2, the following typedef’d types have been assumed: char_t // plain 8 bit character uint8_t // unsigned 8 bit integer uint16_t // unsigned 16 bit integer uint32_t // unsigned 32 bit integer int8_t // signed 8 bit integer int16_t // signed 16 bit integer int32_t // signed 32 bit integer float32_t // 32 bit floating-point float64_t // 64 bit floating-point Note that the bool and wchar_t types do not have typedefs. Non-specific variable names are constructed to give an indication of the type. For example: uint8_t u8a; int32_t s32a; 5.6 Understanding the issue references Where a rule is aimed at a specific issue within ISO/IEC 14882:2003 [1], then a reference to the standard is indicated in square brackets after the rule. This serves two purposes. Firstly, a reader may wish to gain a fuller understanding of the rationale behind the rule (for example when considering a request for a deviation) by consulting the standard. Secondly, this gives extra information about the nature of the problem. Rules that do not have an Issue Reference may have originated from a contributing company’s in- house standard, or have been suggested by a reviewer, or be widely accepted “good practice”. A key to the references, and advice on interpreting them, is given below.

Key to the source references Reference Source Unspecified Unspecified behaviour detailed within the C++ standard Undefined Undefined behaviour detailed within the C++ standard Indeterminate Undefined behaviour that arises due to an omission in the C++ standard of an explicit definition of behaviour Implementation Implementation-defined behaviour detailed within the C++ standard NDR Behaviour within the C++ standard for which no diagnostic is required IEC 61508 IEC 61508:1998–2000 [12]

Where numbers follow the reference, they have the following meanings: • For language issues, the section and paragraph number (if appropriate) of the relevant part of the standard are given, i.e. 1.2(3) would indicate Section 1.2, Paragraph 3. • In other references, the relevant section number is given (unless stated otherwise).

15 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 5. Introduction to the rules (continued)

Issue references Where a rule is based on issues within ISO/IEC 14882:2003 [1], it is helpful for the reader to understand the distinction between “Unspecified”, “Undefined”, “Indeterminate”, “Implementation- Defined” and “NDR” issues.

Unspecified These are language constructs that must compile successfully, but in which the compiler writer has some freedom as to what the construct does. “Order of evaluation” is an example of this. It is unwise to place any reliance on the compiler behaving in a particular way. The compiler need not even behave consistently across all uses of a construct.

Undefined These are essentially programming errors for which the compiler is not obliged to issue a diagnostic (error message). Examples are invalid escape sequences or attempting to modify a string literal. These are particularly important from a safety point of view, as they represent programming errors that may not necessarily be trapped by the compiler.

Indeterminate This is similar to “Undefined”, but where ISO/IEC 14882:2003 [1] omits an explicit definition of behaviour.

Implementation-defined These are similar to the “Unspecified” issues, the main difference being that the compiler writer must take a consistent approach and document it. In other words, the functionality can vary from one compiler to another, making code non-portable, but on any one compiler the behaviour should be well defined. An example of this is the behaviour of the integer division and remainder operators “/” and “%” when applied to one positive and one negative integer. These tend to be less critical from a safety point of view, provided the compiler writer has fully documented their approach and then implemented it consistently. It is advisable to avoid these issues where possible.

NDR “No diagnostic required” (NDR) conditions are those that may lead to program errors, but for which the complier is not required to issue a diagnostic (error message).

5.7 Scope of rules While the majority of rules can be applied within a single translation unit, all rules shall be applied with the widest possible interpretation. In general, the intent is that all the rules shall be applied to templates. However, some rules are only meaningful for instantiated templates. Unless otherwise specified, all rules shall apply to implicitly-declared or implicitly-defined special member functions (e.g. default constructor, copy constructor, copy assignment operator and destructor).

16 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules Rules6.

Appendix C contains a glossary of terms that are used in the formation of the rules that are presented within this section. 6.0 Language independent issues 6.0.1 Unnecessary constructs An unnecessary construct by itself is benign and therefore leads to no faults, but it is a defect. However, it is possible that these defects may be due to errors and hence they may be coupled to, or indicate faults. The following rules address the need to reduce the number of these defects. The attempt to remove all such constructs may reveal the underlying fault if one is present. The absence of such constructs leads to code that is more readable, faster executing and more easily maintained. In addition, software analysis tools can produce more accurate results. The presence of infeasible code, for example, may lead to false positive and false negative messages from static analysis tools. In dynamic analysis, it prevents the achievement of required coverage metrics. Readability is impaired, as also is maintainability.

Rule 0–1–1 (Required) A project shall not contain unreachable code.

Rationale Code is unreachable if there is no syntactic (control flow) path to it. If such code exists, it is unclear if this is intentional or simply that an appropriate path has been accidentally omitted. Compilers may choose not to generate code for these constructs, meaning that, even if the unreachable code is intentional, it may not be present in the final executable code. Missing statements, often caused by editing activities, are a common source of unreachable code.

Example

int16_t with_unreach ( int16_t para ) { int16_t local; local = 0; switch ( para ) { local = para; // unreachable – Non-compliant case 1: { break; } default: { break; } } return para; para++; // unreachable – Non-compliant }

17 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules

Rule 0–1–2 (Required) A project shall not contain infeasible paths.

Rationale Infeasible paths occur where there is a syntactic path but the semantics ensure that the control flow path cannot be executed by any input data. One of the major problems here is the explosion of infeasible paths caused by: • if … else statement sequences; • Sequences of poorly chosen loop constructs Errors in conditions and poorly designed logic contribute to this problem. It is always possible to rewrite the code to eliminate these constructs. This process may then reveal faults. There is the possibility that protective coding techniques generate infeasible code. This code is usually executable (and hence feasible) in a unit testing environment.

Example

void infeas ( uint8_t para, uint8_t outp ) { // The condition below will always be true hence the path // for the false condition is infeasible. Non-compliant. if ( para >= 0U ) { outp = 1U; } // The following if statement combines with the if // statement above to give four paths. One from // the first condition is already infeasible and // the condition below combined with assignment above // makes the false branch infeasible. There is therefore // only one feasible path through this code. if ( outp == 1U ) { outp = 0U; } } enum ec { RED, BLUE, GREEN } col; if ( col <= GREEN ) // Non-compliant – always true { // Will always get here } else { // Will never get here } // The following ifs exhibit similar behaviour. // Note that u16a is a 16-bit unsigned integer // and s8a is an 8-bit signed integer. if ( u16a < 0U ) // Non-compliant – u16a is always >= 0 if ( u16a <= 0xffffU ) // Non-compliant – always true

18 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

if ( s8a < 130 ) // Non-compliant – always true if ( ( s8a < 10 ) && ( s8a > 20 ) ) // Non-compliant – always false if ( ( s8a < 10 ) || ( s8a > 5 ) ) // Non-compliant – always true // Nested conditions can also cause problems if ( s8a > 10 ) { if ( s8a > 5 ) // Non-compliant, unless s8a volatile { // Will always get here. } }

Rule 0–1–3 (Required) A project shall not contain unused variables.

Rationale Variables declared and never used in a project constitute noise and may indicate that the wrong variable name has been used somewhere. Removing these declarations reduces the possibility that they may later be used instead of the correct variable. If padding is used within bit-fields, then the padding member should be unnamed to avoid violation of this rule.

Example

extern void usefn ( int16_t a, int16_t b ); class C { ... }; C c; // Non-compliant - unused void withunusedvar ( void ) { int16_t unusedvar; // Non-compliant – unused struct s_tag { signed int a : 3; signed int pad : 1; // Non-compliant – should be unnamed signed int b : 2; } s_var; s_var.a = 0; s_var.b = 0; usefn ( s_var.a, s_var.b ); }

Rule 0–1–4 (Required) A project shall not contain non-volatile POD variables having only one use.

Rationale With the exception of volatile variables, variables declared and used only once do not contribute to program computations. A use is either an assignment (explicit initialization) or a reference.

19 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

These variables are essentially noise but their presence may indicate that the wrong variable has been used elsewhere. Missing statements contribute to this problem.

Example

const int16_t x = 19; // Compliant const int16_t y = 21; // Non-compliant void usedonlyonce ( void ) { int16_t once_1 = 42; // Non-compliant int16_t once_2; once_2 = x ; // Non-compliant } Note that x is compliant as there are two uses, firstly when initialized and secondly when assigned to once_2.

Rule 0–1–5 (Required) A project shall not contain unused type declarations.

Rationale If a type is declared but not used, then it is unclear to a reviewer if the type is redundant or it has been left unused by mistake. See Section 3.5 for associated library issues.

Example

int16_t unusedtype() { typedef int16_t local_Type; // Non-compliant return 67; }

Rule 0–1–6 (Required) A project shall not contain instances of non- volatile variables being given values that are never subsequently used.

Rationale Technically known as a DU dataflow anomaly, this is a process whereby a variable is given a value that is subsequently never used. At best this is inefficient, but may indicate a genuine problem. Often the presence of these constructs is due to the wrong choice of statement aggregates such as loops.

Exception Loop control variables (see Section 6.6.5) are exempt from this rule.

Example

int16_t critical ( int16_t i, int16_t j ) { int16_t result = 0; int16_t k = ( 3 * i ) + ( j * j );

20 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

// Should k be checked here? if ( f2 ( ) ) { // k will only be tested here if f2 returns true // Initialization of k could be moved here if ( k > 0 ) { throw ( 42 ); } } // Non-compliant – value of k not used if f2 ( ) returns false return ( result ); } void unusedvalue ( int16_t arr[ 20 ] ) { int16_t j; j = 2; for ( int16_t i = 1; i < 10; i++ ) { arr[ i ] = arr[ j ]; j++; // Non-compliant – the value assigned to j } // on the final loop is never used. } void nounusedvalue ( int16_t arr[ 20 ] ) { for ( int16_t i = 1; i < 10; i++ ) { arr[ i ] = arr[ i + 2 ]; } }

Rule 0–1–7 (Required) The value returned by a function having a non-void return type that is not an overloaded operator shall always be used.

Rationale In C++ it is possible to call a function without using the return value, which may be an error. The return value of a function shall always be used. Overloaded operators are excluded, as they should behave in the same way as built-in operators.

Exception

The return value of a function may be discarded by use of a (void) cast.

Example

uint16_t func ( uint16_t para1 ) { return para1; }

21 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

void discarded ( uint16_t para2 ) { func ( para2 ); // value discarded – Non-compliant (void)func ( para2 ); // Compliant } See also Rule 5–2–4

Rule 0–1–8 (Required) All functions with void return type shall have external side effect(s).

Rationale A function which does not return a value and which does not have external side effects will only consume time and will not contribute to the generation of any outputs, which may not meet developer expectations. The following are examples of external side effects: • Reading or writing to a file, stream, etc.; • Changing the value of a non local variable; • Changing the value of an argument having reference type; • Using a volatile object; • Raising an exception.

Example

void pointless ( void ) // Non-compliant – no external side effects { int16_t local; local = 0; }

Rule 0–1–9 (Required) There shall be no dead code.

Rationale Any executed statement whose removal would not affect program output constitutes dead code (also know as redundant code). It is unclear to a reviewer if this is intentional or has occurred due to an error.

Example

int16_t has_dead_code ( int16_t para ) { int16_t local = 99; para = para + local; local = para; // dead code – Non-compliant

22 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

if ( 0 == local ) // dead code – Non-compliant { // dead code – Non-compliant local++; // dead code – Non-compliant } // dead code – Non-compliant return para; }

Rule 0–1–10 (Required) Every defined function shall be called at least once.

Rationale Functions or procedures that are not called may be symptomatic of a serious problem, such as missing paths. Note that an unused prototype is not a violation of this rule. See Section 3.5 for associated library issues.

Example

void f1 ( ) { } void f2 ( ) // Non-compliant { } void f3 ( ); // Compliant prototype int32_t main ( ) { f1 ( ); return ( 0 ); }

Rule 0–1–11 (Required) There shall be no unused parameters (named or unnamed) in non-virtual functions.

Rationale Unused function parameters are often due to design changes and can lead to mismatched parameter lists.

Exception An unnamed parameter in the definition of a function that is used as a callback does not violate this rule.

Example

typedef int16_t ( * CallbackFn )( int16_t a, int16_t b ); int16_t Callback_1 ( int16_t a, int16_t b ) // Compliant { return a + b; }

23 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

int16_t Callback_2 ( int16_t a, int16_t b ) // Non-compliant { return a; } int16_t Callback_3 ( int16_t, int16_t b ) // Compliant by exception { return b; } void Dispatch ( int16_t n, int16_t a, int16_t b, int16_t c, // Non-compliant int16_t ) // Non-compliant if Dispatch not a callback. { CallbackFn pFn; switch ( n ) { case 0: pFn = &Callback_1; break; case 1: pFn = &Callback_2; break; default: pFn = &Callback_3; break; } ( *pFn )( a, b ); } See also Rule 0–1–12

Rule 0–1–12 (Required) There shall be no unused parameters (named or unnamed) in the set of parameters for a virtual function and all the functions that override it.

Rationale Unused function parameters are often due to design changes and can lead to mismatched parameter lists.

Example

class A { public: virtual void withunusedpara ( uint16_t * para1, int16_t unusedpara ) = 0; virtual void withoutunusedpara ( uint16_t * para1, int16_t & para2 ) = 0; };

24 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

class B1: public A { public: virtual void withunusedpara ( uint16_t * para1, int16_t unusedpara ) { *para1 = 1U; } virtual void withoutunusedpara ( uint16_t * para1, int16_t & para2 ) { *para1 = 1U; } }; class B2: public A { public: virtual void withunusedpara ( uint16_t * para1, int16_t unusedpara ) { *para1 = 1U; } virtual void withoutunusedpara ( uint16_t * para1, int16_t & para2 ) { para2 = 0; } }; See also Rule 0–1–11

6.0.2 Storage

Rule 0–2–1 (Required) An object shall not be assigned to an overlapping object.

[Undefined 5.17(8)] Rationale Assigning between objects that have an overlap in their physical storage leads to undefined behaviour.

25 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

Example

struct s { int16_t m1 [ 32 ]; }; struct t { int32_t m2; struct s m3; }; void fn ( ) { union // Breaks Rule 9–5–1 { struct s u1; struct t u2; } a; a.u2.m3 = a.u1; // Non-compliant } See also Rule 9–5–1

6.0.3 Runtime failures

Rule 0–3–1 (Document) Minimization of run-time failures shall be ensured by the use of at least one of: (a) static analysis tools/techniques; (b) dynamic analysis tools/techniques; (c) explicit coding of checks to handle run-time faults.

Rationale Run-time checking is an issue (not specific to C++) to which developers need to pay special attention, especially as the C++ language is weak in its provision of any run-time checking. C++ implementations are not required to perform many of the dynamic checks that are necessary for robust software. It is therefore an issue that C++ developers need to consider carefully, adding dynamic checks to code wherever there is the potential for run-time errors to occur. Where expressions consist only of values within a well-defined range, a run-time check may not be necessary, provided it can be demonstrated that for all values within the defined range the exception cannot occur. Such a demonstration, if used, should be documented along with the assumptions on which it depends. However, if adopting this approach, be very careful about subsequent modifications of the code that may invalidate the assumptions, or of the assumptions changing for any other reason. The following notes give some guidance on areas where consideration needs to be given to the provision of dynamic checks.

26 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

• arithmetic errors This includes errors occurring in the evaluation of expressions, such as overflow, underflow, division by zero or loss of significant bits through shifting. In considering integer overflow, note that unsigned integer calculations do not strictly overflow (producing undefined values), but the values wrap around (producing defined, but possibly unexpected, values). • pointer arithmetic Ensure that when an address is calculated dynamically the computed address is reasonable and points somewhere meaningful. In particular it should be ensured that if a pointer points within a structure or array, then when the pointer has been incremented or otherwise altered it still points to the same structure or array. See Rule 5–0–15, Rule 5–0–16, Rule 5–0–17 and Rule 5–0–18 for restrictions on pointer arithmetic. • array bound errors Ensure that array indices are within the bounds of the array size before using them to index the array. • function arguments Function arguments should be validated. • pointer dereferencing Where a function returns a pointer and that pointer is subsequently de-referenced the program should first check that the pointer is not NULL. Within a function, it is relatively straightforward to reason about which pointers may or may not hold NULL values. Across function boundaries, especially when calling functions defined in other source files or libraries, it is much more difficult. // Given a pointer to a message, check the message header and return // a pointer to the body of the message or NULL if the message is // invalid. const char_t *msg_body ( const char_t * msg ) { const char_t * body = NULL; if ( msg != NULL ) { if ( msg_header_valid ( msg ) ) { body = &msg [ MSG_HEADER_SIZE ]; } } return ( body ); } ... char_t msg_buffer [ MAX_MSG_SIZE ]; const char_t * payload; ... payload = msg_body ( msg_buffer ); if ( payload != NULL ) { // process the message payload }

27 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 6. Rules (continued)

The techniques that will be employed to minimize run‑time failures should be planned and documented, e.g. in design standards, test plans, static analysis configuration files, code review checklists.

Rule 0–3–2 (Required) If a function generates error information, then that error information shall be tested.

Rationale A function (whether it is part of the standard library, a third party library or a user defined function) may provide some means of indicating the occurrence of an error. This may be via a global error flag, a parametric error flag, a special return value or some other means. Whenever such a mechanism is provided by a function the calling program shall check for the indication of an error as soon as the function returns. Note, however, that the checking of input values to functions is considered a more robust means of error prevention than trying to detect errors after the function has completed.

Example

extern void fn3 ( int32_t i, bool & flag ); int32_t fn1 ( int32_t i ) { int32_t result = 0; bool success = false; fn3 ( i, success ); // Non-compliant - success not checked return result; } int32_t fn2 ( int32_t i ) { int32_t result = 0; bool success = false; fn3 ( i, success ); // Compliant - success checked if ( !success ) { throw 42; } return result; }

See also Rule 0–3–2

6.27 Input/output library 6.27.0 General

Rule 27–0–1 (Required) The stream input/output library shall not be used.

Rationale This includes file and I/O functions fgetpos, fopen, ftell, gets, perror, remove, rename, etc. Streams and file I/O have a large number of unspecified, undefined and implementation-defined behaviours associated with them.

Example

#include // Non-compliant void fn ( ) { char_t array [ 10 ]; gets ( array ); // Can lead to buffer over-run }

173 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 7. References 7. References

[1] ISO/IEC 14882:2003, The C++ Standard Incorporating Technical Corrigendum 1, International Organization for Standardization, 2003. [2] MISRA Development Guidelines for Vehicle Based Software, ISBN 0-9524156-0-7, Motor Industry Research Association, Nuneaton, November 1994. [3] MISRA AC INT Introduction to the MISRA guidelines for the use of automatic code generation in automotive systems, ISBN 978-1-906400-00-2, MIRA Limited, November 2007. [4] CRR80, The Use of Commercial Off-the-Shelf (COTS) Software in Safety Related Applications, ISBN 0-7176-0984-7, HSE Books. [5] ISO 9001:2000, Quality management systems — Requirements, International Organization for Standardization, 2000. [6] ISO 90003:2004, Software engineering — Guidelines for the application of ISO 9001:2000 to computer software, ISO, 2004. [7] The TickIT Guide, Using ISO 9001:2000 for Software Quality Management System Construction, Certification and Continual Improvement, Issue 5, British Standards Institution, 2001. [8] Straker D., C Style: Standards and Guidelines, ISBN 0–13-116898-3, Prentice Hall 1991. [9] Fenton N.E. and Pfleeger S.L., Software Metrics: A Rigorous and Practical Approach, 2nd Edition, ISBN 0-534-95429-1, PWS, 1998. [10] MISRA Report 5, Software Metrics, Motor Industry Research Association, Nuneaton, February 1995. [11] MISRA Report 6, Verification and Validation, Motor Industry Research Association, Nuneaton, February 1995. [12] IEC 61508, Functional safety of electrical/electronic/programmable electronic safety- related systems, International Electromechanical Commission, in 7 parts published between 1998 and 2000. [13] Goldberg D., What Every Computer Scientist Should Know about Floating-Point Arithmetic, Computing Surveys, March 1991. [14] ANSI/IEEE Std 754, IEEE Standard for Binary Floating-Point Arithmetic, 1985. [15] ISO/IEC 10646:2003, Information technology — Universal Multiple-Octet Coded Character Sets (UCS), International Organization for Standardization, 2003. [16] ISO/IEC 9899:1990, Programming Languages — C, International Organization for Standardization, 1990. [17] Hill M.G. and Whiting E.V, An Investigation of the Unpredictable Features of the C++ Language, QINETIQ/KI/TIM/TR043014, QinetiQ, May 2004. [18] High-Integrity C++ Coding Standard Manual Version 2.2, The Programming Research Group, May 2004.

174 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 7. References (continued)

[19] Joint Strike Fighter Air Vehicle C++ Coding Standards for the System Development and Demonstration Program, Document Number 2RDU00001 Rev C, Lockheed Martin, December 2005. [20] Henricson M., Nyquist E., Industrial Strength C++, ISBN 0-13-120965-5, Prentice Hall, 1997. [21] Sutter H., Exceptional C++, ISBN 0-201-61562-2, Addison-Wesley, 1999. [22] Koenig A., C Traps and Pitfalls, ISBN 0-201-17928-8, Addison-Wesley, 1988. [23] Hatton L., Safer C, ISBN 0-07-707640-0, McGraw-Hill, 1994. [24] Dewhurst S., C++ Gotchas, ISBN 0-321-12518-5, Addison-Wesley, 2003. [25] Meyers S., More Effective C++, ISBN 0-201-63371-X, Addison-Wesley, 1996. [26] Meyers S., Effective C++, ISBN 0-321-33487-6 (Third Edition), Addison-Wesley, 2005.

175 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A Appendix A: Summary of rules

Unnecessary constructs Rule 0–1–1 (Required) A project shall not contain unreachable code. Rule 0–1–2 (Required) A project shall not contain infeasible paths. Rule 0–1–3 (Required) A project shall not contain unused variables. Rule 0–1–4 (Required) A project shall not contain non-volatile POD variables having only one use. Rule 0–1–5 (Required) A project shall not contain unused type declarations. Rule 0–1–6 (Required) A project shall not contain instances of non-volatile variables being given values that are never subsequently used. Rule 0–1–7 (Required) The value returned by a function having a non-void return type that is not an overloaded operator shall always be used. Rule 0–1–8 (Required) All functions with void return type shall have external side effect(s). Rule 0–1–9 (Required) There shall be no dead code. Rule 0–1–10 (Required) Every defined function shall be called at least once. Rule 0–1–11 (Required) There shall be no unused parameters (named or unnamed) in non- virtual functions. Rule 0–1–12 (Required) There shall be no unused parameters (named or unnamed) in the set of parameters for a virtual function and all the functions that override it.

Storage Rule 0–2–1 (Required) An object shall not be assigned to an overlapping object.

Runtime failures Rule 0–3–1 (Document) Minimization of run-time failures shall be ensured by the use of at least one of: (a) static analysis tools/techniques; (b) dynamic analysis tools/techniques; (c) explicit coding of checks to handle run-time faults. Rule 0–3–2 (Required) If a function generates error information, then that error information shall be tested.

Arithmetic Rule 0–4–1 (Document) Use of scaled-integer or fixed-point arithmetic shall be documented. Rule 0–4–2 (Document) Use of floating-point arithmetic shall be documented.

176 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Rule 0–4–3 (Document) Floating-point implementations shall comply with a defined floating- point standard.

Language Rule 1–0–1 (Required) All code shall conform to ISO/IEC 14882:2003 “The C++ Standard Incorporating Technical Corrigendum 1”. Rule 1–0–2 (Document) Multiple compilers shall only be used if they have a common, defined interface. Rule 1–0–3 (Document) The implementation of integer division in the chosen compiler shall be determined and documented.

Character sets Rule 2–2–1 (Document) The character set and the corresponding encoding shall be documented.

Trigraph sequences Rule 2–3–1 (Required) Trigraphs shall not be used.

Alternative tokens Rule 2–5–1 (Advisory) Digraphs should not be used.

Comments

Rule 2–7–1 (Required) The character sequence /* shall not be used within a C-style comment. Rule 2–7–2 (Required) Sections of code shall not be “commented out” using C-style comments. Rule 2–7–3 (Advisory) Sections of code should not be “commented out” using C++ comments.

Identifiers Rule 2–10–1 (Required) Different identifiers shall be typographically unambiguous. Rule 2–10–2 (Required) Identifiers declared in an inner scope shall not hide an identifier declared in an outer scope. Rule 2–10–3 (Required) A typedef name (including qualification, if any) shall be a unique identifier. Rule 2–10–4 (Required) A class, union or enum name (including qualification, if any) shall be a unique identifier. Rule 2–10–5 (Advisory) The identifier name of a non-member object or function with static storage duration should not be reused. Rule 2–10–6 (Required) If an identifier refers to a type, it shall not also refer to an object or a function in the same scope.

177 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Literals Rule 2–13–1 (Required) Only those escape sequences that are defined in ISO/IEC 14882:2003 shall be used. Rule 2–13–2 (Required) Octal constants (other than zero) and octal escape sequences (other than “\0”) shall not be used. Rule 2–13–3 (Required) A “U ” suffix shall be applied to all octal or hexadecimal integer literals of unsigned type. Rule 2–13–4 (Required) Literal suffixes shall be upper case. Rule 2–13–5 (Required) Narrow and wide string literals shall not be concatenated.

Declarations and definitions Rule 3–1–1 (Required) It shall be possible to include any header file in multiple translation units without violating the One Definition Rule. Rule 3–1–2 (Required) Functions shall not be declared at block scope. Rule 3–1–3 (Required) When an array is declared, its size shall either be stated explicitly or defined implicitly by initialization.

One Definition Rule Rule 3–2–1 (Required) All declarations of an object or function shall have compatible types. Rule 3–2–2 (Required) The One Definition Rule shall not be violated. Rule 3–2–3 (Required) A type, object or function that is used in multiple translation units shall be declared in one and only one file. Rule 3–2–4 (Required) An identifier with external linkage shall have exactly one definition.

Declarative regions and scope Rule 3–3–1 (Required) Objects or functions with external linkage shall be declared in a header file. Rule 3–3–2 (Required) If a function has internal linkage then all re-declarations shall include the static storage class specifier.

Name lookup Rule 3–4–1 (Required) An identifier declared to be an object or type shall be defined in a block that minimizes its visibility.

Types Rule 3–9–1 (Required) The types used for an object, a function return type, or a function parameter shall be token-for-token identical in all declarations and re-declarations.

178 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Rule 3–9–2 (Advisory) typedefs that indicate size and signedness should be used in place of the basic numerical types. Rule 3–9–3 (Required) The underlying bit representations of floating-point values shall not be used.

Integral promotions Rule 4–5–1 (Required) Expressions with type bool shall not be used as operands to built-in operators other than the assignment operator =, the logical operators &&, ||, !, the equality operators == and !=, the unary & operator, and the conditional operator. Rule 4–5–2 (Required) Expressions with type enum shall not be used as operands to built- in operators other than the subscript operator [ ], the assignment operator =, the equality operators == and !=, the unary & operator, and the relational operators <, <=, >, >=. Rule 4–5–3 (Required) Expressions with type (plain) char and wchar_t shall not be used as operands to built-in operators other than the assignment operator =, the equality operators == and !=, and the unary & operator.

Pointer conversions Rule 4–10–1 (Required) NULL shall not be used as an integer value. Rule 4–10–2 (Required) Literal zero (0) shall not be used as the null-pointer-constant.

Expressions Rule 5–0–1 (Required) The value of an expression shall be the same under any order of evaluation that the standard permits. Rule 5–0–2 (Advisory) Limited dependence should be placed on C++ operator precedence rules in expressions. Rule 5–0–3 (Required) A cvalue expression shall not be implicitly converted to a different underlying type. Rule 5–0–4 (Required) An implicit integral conversion shall not change the signedness of the underlying type. Rule 5–0–5 (Required) There shall be no implicit floating-integral conversions. Rule 5–0–6 (Required) An implicit integral or floating-point conversion shall not reduce the size of the underlying type. Rule 5–0–7 (Required) There shall be no explicit floating-integral conversions of a cvalue expression. Rule 5–0–8 (Required) An explicit integral or floating-point conversion shall not increase the size of the underlying type of a cvalue expression. Rule 5–0–9 (Required) An explicit integral conversion shall not change the signedness of the underlying type of a cvalue expression.

179 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Rule 5–0–10 (Required) If the bitwise operators ~ and << are applied to an operand with an underlying type of unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand. Rule 5–0–11 (Required) The plain char type shall only be used for the storage and use of character values. Rule 5–0–12 (Required) signed char and unsigned char type shall only be used for the storage and use of numeric values. Rule 5–0–13 (Required) The condition of an if-statement and the condition of an iteration- statement shall have type bool. Rule 5–0–14 (Required) The first operand of a conditional-operator shall have type bool. Rule 5–0–15 (Required) Array indexing shall be the only form of pointer arithmetic. Rule 5–0–16 (Required) A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array. Rule 5–0–17 (Required) Subtraction between pointers shall only be applied to pointers that address elements of the same array.

Rule 5–0–18 (Required) >, >=, <, <= shall not be applied to objects of pointer type, except where they point to the same array. Rule 5–0–19 (Required) The declaration of objects shall contain no more than two levels of pointer indirection. Rule 5–0–20 (Required) Non-constant operands to a binary bitwise operator shall have the same underlying type. Rule 5–0–21 (Required) Bitwise operators shall only be applied to operands of unsigned underlying type.

Postfix expressions

Rule 5–2–1 (Required) Each operand of a logical && or || shall be a postfix‑expression. Rule 5–2–2 (Required) A pointer to a virtual base class shall only be cast to a pointer to a derived class by means of dynamic_cast. Rule 5–2–3 (Advisory) Casts from a base class to a derived class should not be performed on polymorphic types. Rule 5–2–4 (Required) C-style casts (other than void casts) and functional notation casts (other than explicit constructor calls) shall not be used. Rule 5–2–5 (Required) A cast shall not remove any const or volatile qualification from the type of a pointer or reference. Rule 5–2–6 (Required) A cast shall not convert a pointer to a function to any other pointer type, including a pointer to function type. Rule 5–2–7 (Required) An object with pointer type shall not be converted to an unrelated pointer type, either directly or indirectly.

180 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Rule 5–2–8 (Required) An object with integer type or pointer to void type shall not be converted to an object with pointer type. Rule 5–2–9 (Advisory) A cast should not convert a pointer type to an integral type.

Rule 5–2–10 (Advisory) The increment (++) and decrement (--) operators should not be mixed with other operators in an expression.

Rule 5–2–11 (Required) The comma operator, && operator and the || operator shall not be overloaded. Rule 5–2–12 (Required) An identifier with array type passed as a function argument shall not decay to a pointer.

Unary expressions

Rule 5–3–1 (Required) Each operand of the ! operator, the logical && or the logical || operators shall have type bool. Rule 5–3–2 (Required) The unary minus operator shall not be applied to an expression whose underlying type is unsigned.

Rule 5–3–3 (Required) The unary & operator shall not be overloaded. Rule 5–3–4 (Required) Evaluation of the operand to the sizeof operator shall not contain side effects.

Shift operators Rule 5–8–1 (Required) The right hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left hand operand.

Logical AND operator

Rule 5–14–1 (Required) The right hand operand of a logical && or || operator shall not contain side effects.

Assignment operators Rule 5–17–1 (Required) The semantic equivalence between a binary operator and its assignment operator form shall be preserved.

Comma operator Rule 5–18–1 (Required) The comma operator shall not be used.

Constant expressions Rule 5–19–1 (Advisory) Evaluation of constant unsigned integer expressions should not lead to wrap-around.

Expression statement Rule 6–2–1 (Required) Assignment operators shall not be used in sub-expressions.

181 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Rule 6–2–2 (Required) Floating-point expressions shall not be directly or indirectly tested for equality or inequality. Rule 6–2–3 (Required) Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment, provided that the first character following the null statement is a white‑space character.

Compound statement Rule 6–3–1 (Required) The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement.

Selection statements Rule 6–4–1 (Required) An if ( condition ) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement. Rule 6–4–2 (Required) All if … else if constructs shall be terminated with an else clause. Rule 6–4–3 (Required) A switch statement shall be a well-formed switch statement. Rule 6–4–4 (Required) A switch-label shall only be used when the most closely-enclosing compound statement is the body of a switch statement. Rule 6–4–5 (Required) An unconditional throw or break statement shall terminate every non‑empty switch-clause. Rule 6–4–6 (Required) The final clause of a switch statement shall be the default-clause. Rule 6–4–7 (Required) The condition of a switch statement shall not have bool type. Rule 6–4–8 (Required) Every switch statement shall have at least one case-clause.

Iteration statements Rule 6–5–1 (Required) A for loop shall contain a single loop-counter which shall not have floating type.

Rule 6–5–2 (Required) If loop-counter is not modified by -- or ++, then, within condition, the loop-counter shall only be used as an operand to <=, <, > or >=. Rule 6–5–3 (Required) The loop-counter shall not be modified within condition or statement.

Rule 6–5–4 (Required) The loop-counter shall be modified by one of: --, ++, -=n, or +=n; where n remains constant for the duration of the loop. Rule 6–5–5 (Required) A loop-control-variable other than the loop-counter shall not be modified within condition or expression. Rule 6–5–6 (Required) A loop-control-variable other than the loop-counter which is modified in statement shall have type bool.

Jump statements Rule 6–6–1 (Required) Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement.

182 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Rule 6–6–2 (Required) The goto statement shall jump to a label declared later in the same function body. Rule 6–6–3 (Required) The continue statement shall only be used within a well-formed for loop. Rule 6–6–4 (Required) For any iteration statement there shall be no more than one break or goto statement used for loop termination. Rule 6–6–5 (Required) A function shall have a single point of exit at the end of the function.

Specifiers Rule 7–1–1 (Required) A variable which is not modified shall be const qualified. Rule 7–1–2 (Required) A pointer or reference parameter in a function shall be declared as pointer to const or reference to const if the corresponding object is not modified.

Enumeration declarations Rule 7–2–1 (Required) An expression with enum underlying type shall only have values corresponding to the enumerators of the enumeration.

Namespaces Rule 7–3–1 (Required) The global namespace shall only contain main, namespace declarations and extern "C" declarations. Rule 7–3–2 (Required) The identifier main shall not be used for a function other than the global function main. Rule 7–3–3 (Required) There shall be no unnamed namespaces in header files. Rule 7–3–4 (Required) using-directives shall not be used. Rule 7–3–5 (Required) Multiple declarations for an identifier in the same namespace shall not straddle a using-declaration for that identifier. Rule 7–3–6 (Required) using-directives and using-declarations (excluding class scope or function scope using-declarations) shall not be used in header files.

The asm declaration Rule 7–4–1 (Document) All usage of assembler shall be documented. Rule 7–4–2 (Required) Assembler instructions shall only be introduced using the asm declaration. Rule 7–4–3 (Required) Assembly language shall be encapsulated and isolated.

Linkage specifications Rule 7–5–1 (Required) A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function.

183 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Rule 7–5–2 (Required) The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist. Rule 7–5–3 (Required) A function shall not return a reference or a pointer to a parameter that is passed by reference or const reference. Rule 7–5–4 (Advisory) Functions should not call themselves, either directly or indirectly.

Declarators — General Rule 8–0–1 (Required) An init-declarator-list or a member-declarator-list shall consist of a single init-declarator or member-declarator respectively.

Meaning of declarators Rule 8–3–1 (Required) Parameters in an overriding virtual function shall either use the same default arguments as the function they override, or else shall not specify any default arguments.

Function definitions Rule 8–4–1 (Required) Functions shall not be defined using the ellipsis notation. Rule 8–4–2 (Required) The identifiers used for the parameters in a re-declaration of a function shall be identical to those in the declaration. Rule 8–4–3 (Required) All exit paths from a function with non-void return type shall have an explicit return statement with an expression. Rule 8–4–4 (Required) A function identifier shall either be used to call the function or it shall be preceded by &.

Declarators — Initializers Rule 8–5–1 (Required) All variables shall have a defined value before they are used. Rule 8–5–2 (Required) Braces shall be used to indicate and match the structure in the non- zero initialization of arrays and structures.

Rule 8–5–3 (Required) In an enumerator list, the = construct shall not be used to explicitly initialize members other than the first, unless all items are explicitly initialized.

Member functions Rule 9–3–1 (Required) const member functions shall not return non-const pointers or references to class-data. Rule 9–3–2 (Required) Member functions shall not return non-const handles to class-data. Rule 9–3–3 (Required) If a member function can be made static then it shall be made static, otherwise if it can be made const then it shall be made const.

Unions Rule 9–5–1 (Required) Unions shall not be used.

184 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Bit-fields Rule 9–6–1 (Document) When the absolute positioning of bits representing a bit-field is required, then the behaviour and packing of bit-fields shall be documented. Rule 9–6–2 (Required) Bit-fields shall be either bool type or an explicitly unsigned or signed integral type. Rule 9–6–3 (Required) Bit-fields shall not have enum type. Rule 9–6–4 (Required) Named bit-fields with signed integer type shall have a length of more than one bit.

Multiple base classes Rule 10–1–1 (Advisory) Classes should not be derived from virtual bases. Rule 10–1–2 (Required) A base class shall only be declared virtual if it is used in a diamond hierarchy. Rule 10–1–3 (Required) An accessible base class shall not be both virtual and non-virtual in the same hierarchy.

Member name lookup Rule 10–2–1 (Advisory) All accessible entity names within a multiple inheritance hierarchy should be unique.

Virtual functions Rule 10–3–1 (Required) There shall be no more than one definition of each virtual function on each path through the inheritance hierarchy. Rule 10–3–2 (Required) Each overriding virtual function shall be declared with the virtual keyword. Rule 10–3–3 (Required) A virtual function shall only be overridden by a pure virtual function if it is itself declared as pure virtual.

Member access control — General Rule 11–0–1 (Required) Member data in non-POD class types shall be private.

Constructors Rule 12–1–1 (Required) An object’s dynamic type shall not be used from the body of its constructor or destructor. Rule 12–1–2 (Advisory) All constructors of a class should explicitly call a constructor for all of its immediate base classes and all virtual base classes. Rule 12–1–3 (Required) All constructors that are callable with a single argument of fundamental type shall be declared explicit.

185 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Copying class objects Rule 12–8–1 (Required) A copy constructor shall only initialize its base classes and the non- static members of the class of which it is a member. Rule 12–8–2 (Required) The copy assignment operator shall be declared protected or private in an abstract class.

Template declarations Rule 14–5–1 (Required) A non-member generic function shall only be declared in a namespace that is not an associated namespace. Rule 14–5–2 (Required) A copy constructor shall be declared when there is a template constructor with a single parameter that is a generic parameter. Rule 14–5–3 (Required) A copy assignment operator shall be declared when there is a template assignment operator with a parameter that is a generic parameter.

Name resolution Rule 14–6–1 (Required) In a class template with a dependent base, any name that may be found in that dependent base shall be referred to using a qualified-id or this-> Rule 14–6–2 (Required) The function chosen by overload resolution shall resolve to a function declared previously in the translation unit.

Template instantiation and specialization Rule 14–7–1 (Required) All class templates, function templates, class template member functions and class template static members shall be instantiated at least once. Rule 14–7–2 (Required) For any given template specialization, an explicit instantiation of the template with the template-arguments used in the specialization shall not render the program ill-formed. Rule 14–7–3 (Required) All partial and explicit specializations for a template shall be declared in the same file as the declaration of their primary template.

Function template specialization Rule 14–8–1 (Required) Overloaded function templates shall not be explicitly specialized. Rule 14–8–2 (Advisory) The viable function set for a function call should either contain no function specializations, or only contain function specializations.

Exception handling — General Rule 15–0–1 (Document) Exceptions shall only be used for error handling. Rule 15–0–2 (Advisory) An exception object should not have pointer type. Rule 15–0–3 (Required) Control shall not be transferred into a try or catch block using a goto or a switch statement.

186 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Throwing an exception Rule 15–1–1 (Required) The assignment-expression of a throw statement shall not itself cause an exception to be thrown. Rule 15–1–2 (Required) NULL shall not be thrown explicitly.

Rule 15–1–3 (Required) An empty throw (throw;) shall only be used in the compound- statement of a catch handler.

Handling an exception Rule 15–3–1 (Required) Exceptions shall be raised only after start-up and before termination of the program. Rule 15–3–2 (Advisory) There should be at least one exception handler to catch all otherwise unhandled exceptions Rule 15–3–3 (Required) Handlers of a function-try-block implementation of a class constructor or destructor shall not reference non-static members from this class or its bases. Rule 15–3–4 (Required) Each exception explicitly thrown in the code shall have a handler of a compatible type in all call paths that could lead to that point. Rule 15–3–5 (Required) A class type exception shall always be caught by reference. Rule 15–3–6 (Required) Where multiple handlers are provided in a single try-catch statement or function-try-block for a derived class and some or all of its bases, the handlers shall be ordered most-derived to base class. Rule 15–3–7 (Required) Where multiple handlers are provided in a single try-catch statement or function-try-block, any ellipsis (catch-all) handler shall occur last.

Exception specifications Rule 15–4–1 (Required) If a function is declared with an exception-specification, then all declarations of the same function (in other translation units) shall be declared with the same set of type-ids.

Exception handling — Special functions Rule 15–5–1 (Required) A class destructor shall not exit with an exception. Rule 15–5–2 (Required) Where a function’s declaration includes an exception-specification, the function shall only be capable of throwing exceptions of the indicated type(s). Rule 15–5–3 (Required) The terminate() function shall not be called implicitly.

Preprocessing directives — General Rule 16–0–1 (Required) #include directives in a file shall only be preceded by other preprocessor directives or comments.

187 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Rule 16–0–2 (Required) Macros shall only be #define’d or #undef’d in the global namespace. Rule 16–0–3 (Required) #undef shall not be used. Rule 16–0–4 (Required) Function-like macros shall not be defined. Rule 16–0–5 (Required) Arguments to a function-like macro shall not contain tokens that look like preprocessing directives. Rule 16–0–6 (Required) In the definition of a function-like macro, each instance of a parameter shall be enclosed in parentheses, unless it is used as the operand of # or ##. Rule 16–0–7 (Required) Undefined macro identifiers shall not be used in #if or #elif preprocessor directives, except as operands to the defined operator.

Rule 16–0–8 (Required) If the # token appears as the first token on a line, then it shall be immediately followed by a preprocessing token.

Conditional inclusion Rule 16–1–1 (Required) The defined preprocessor operator shall only be used in one of the two standard forms. Rule 16–1–2 (Required) All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related.

Source file inclusion Rule 16–2–1 (Required) The pre-processor shall only be used for file inclusion and include guards. Rule 16–2–2 (Required) C++ macros shall only be used for: include guards, type qualifiers, or storage class specifiers. Rule 16–2–3 (Required) Include guards shall be provided.

Rule 16–2–4 (Required) The ', ", /* or // characters shall not occur in a header file name. Rule 16–2–5 (Advisory) The \ character should not occur in a header file name. Rule 16–2–6 (Required) The #include directive shall be followed by either a or "filename" sequence.

Macro replacement

Rule 16–3–1 (Required) There shall be at most one occurrence of the # or ## operators in a single macro definition.

Rule 16–3–2 (Advisory) The # and ## operators should not be used.

Pragma directive Rule 16–6–1 (Document) All uses of the #pragma directive shall be documented.

188 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix A (continued)

Library introduction — General Rule 17–0–1 (Required) Reserved identifiers, macros and functions in the standard library shall not be defined, redefined or undefined. Rule 17–0–2 (Required) The names of standard library macros and objects shall not be reused. Rule 17–0–3 (Required) The names of standard library functions shall not be overridden. Rule 17–0–4 (Document) All library code shall conform to MISRA C++. Rule 17–0–5 (Required) The setjmp macro and the longjmp function shall not be used.

Language support library — General Rule 18–0–1 (Required) The C library shall not be used. Rule 18–0–2 (Required) The library functions atof, atoi and atol from library shall not be used. Rule 18–0–3 (Required) The library functions abort, exit, getenv and system from library shall not be used. Rule 18–0–4 (Required) The time handling functions of library shall not be used. Rule 18–0–5 (Required) The unbounded functions of library shall not be used.

Language support library — Implementation properties Rule 18–2–1 (Required) The macro offsetof shall not be used.

Language support library — Dynamic memory management Rule 18–4–1 (Required) Dynamic heap memory allocation shall not be used.

Language support library — Other runtime support Rule 18–7–1 (Required) The signal handling facilities of shall not be used.

Diagnostics library — Error numbers Rule 19–3–1 (Required) The error indicator errno shall not be used.

Input/output library — General Rule 27–0–1 (Required) The stream input/output library shall not be used.

189 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B Appendix B: C++ vulnerabilities

Unlike the C Language Reference Manual [16], the C++ LRM (ISO/IEC 14882:2003 [1]) does not include a collated list of the features of the language that are “unspecified”, “undefined”, etc. This annex provides such a list. The extraction of this information from the LRM was funded by the Analysis, Experimentation and Simulation Domain of the UK Ministry of Defence Scientific Research Programme, and is quoted here with permission. Each entry in the list contains the following information: • MISRA Id: an identifier unique to this document, to allow easy reference to particular issues. • ISO Reference: a reference into the LRM, in the form X.Y(Z) being paragraph Z of subsection Y of section X, etc.. • Description: a brief summary of the unspecified etc. behaviour described in the referenced paragraph. • Category: the sort of behaviour described in the referenced paragraph (see below). • MISRA Guidance: which Rule(s) in this document address the described issue. • Source Id: unique identifier used in the document where this table was originally published [17], to allow cross-referencing. The categories are as follows: • Unspecified: A situation where the implementation will have to make some “sensible” choice, but that choice is not predictable by the programmer, e.g. the order in which sub- expressions are evaluated in an expression. • Undefined: A situation where the LRM can give no indication of what behaviour to expect from a program. This behaviour may result in catastrophic failure (a “crash”) or continued execution with some arbitrary data. • Implementation: A situation where the implementation will have to make some “sensible” choice and where that choice has to be documented and be available to the programmer, e.g. the size of integers. • Indeterminate: A sub-category of undefined behaviour, where the LRM says “if condition, the behaviour is ...” but does not say what happens if the condition is not true. • Behaviour that requires no diagnostics: A situation where the LRM permits behaviour that may be unexpected or at odds with previously defined principles, but explicitly the LRM does not require the programmer to be warned.

190 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 1 2.1(1) The mapping of physical source file Implementation 3.01 characters. 2 2.1(2) A character sequence that matches a Undefined 2.01 universal-character-name is produced due to the splicing of physical source lines in the translation process. 3 2.1(2) A non-empty source file does not end in Undefined 2.02 a new line character, or ends in a new line character immediately preceded by a backslash character. 4 2.1(2) Use of an identifier reserved for C++ Behaviour that 5.02 implementations and standard libraries. requires no diagnostics 5 2.1(3) Whether each non-empty sequence of Implementation 3.02 white-space characters other than new line is retained or replaced by one space character. 6 2.1(4) A character sequence that matches a Undefined 2.03 universal-character-name is produced due to token concatenation. 7 2.1(8) Whether the source of the translational Implementation 3.03 units containing the definitions of the templates for the requisite instantiations is required to be available. 8 2.2(3) The values of the members of the Implementation 3.04 execution character sets. 9 2.4(2) An unmatched ' or a " character is Undefined 2.04 encountered on a logical source line during tokenization. 10 2.7(1) A // comment contains a form feed or Behaviour that 5.01 vertical-tab character and does not only requires no have white space characters between it and diagnostics the new-line that terminates the comment. 11 2.8(1) The mapping of the sequences in both Implementation 3.05 forms of header-names. See 16.2(2) 12 2.8(2) The characters ', \, ", /*, or // are Undefined Rule 16–2–4 2.05 encountered between the < and > Rule 16–2–5 delimiters or the characters ', \, /*, or // are encountered between the " delimiters in the two forms of a header name preprocessing token. 13 2.13.1(2) An integer literal cannot be represented by Undefined 2.06 any of the allowed types. 14 2.13.2(1) The value of a multi-character literal. Implementation 3.06

15 2.13.2(2) The value of a wide-character literal Implementation 3.07 containing multiple c-chars. 16 2.13.2(3) The character following a backslash does Undefined Rule 2–13–1 2.07 not give a valid escape sequence.

191 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 17 2.13.2(4) The value of a character literal that falls Implementation 3.08 outside of the implementation defined range for char or w_char. 18 2.13.2(5) The encoding of a universal-character- Implementation 3.09 name where the execution character set has no encoding for the character named. 19 2.13.3(1) The actual value used for a floating Implementation 3.10 literal whose value is not in the range of representable values for its type. 20 2.13.4(2) An attempt is made to modify a string Undefined 2.08 literal. 21 2.13.4(2) Whether all string literals are distinct Implementation 3.11 (stored in non-overlapping objects). 22 2.13.4(3) A narrow string literal token is adjacent to Undefined Rule 2–13–5 2.09 a wide string literal token. 23 3.1(15) A program attempting to access the stored Undefined 2.22 value of an object through an lvalue of other than one of the types specified. 24 3.2(3) A program that does not contain exactly Behaviour that Rule 3–2–1 5.03 one definition for every non-inline function requires no Rule 3–2–4 or object that is used in that program. diagnostics 25 3.2(5) The behaviour of a program if two Undefined Rule 3–2–1 2.10 definitions in separate translation units do Rule 3–2–4 not satisfy the One Definition Rule. 26 3.3.1(1) The value used when a variable is used to Indeterminate 4.01 initialize itself, e.g. int x = x; 27 3.3.6(1) A name N used in a class S does not refer Behaviour that 5.04 Item 2 to the same declaration in its context and requires no when re-evaluated in the completed scope diagnostics of S. 28 3.3.6(1) If reordering member declarations in a Behaviour that 5.05 Item 3 class yields an alternative valid program requires no under certain conditions. diagnostics 29 3.5(10) If a given object or function can be referred Behaviour that 5.06 to by values of different type (after all requires no types adjustments) diagnostics 30 3.6.1(1) Whether a program in a freestanding Implementation 3.12 environment is required to define a main function. 31 3.6.1(1) Start-up and termination in a freestanding Implementation 3.13 environment. 32 3.6.1(2) The type of the main function, though its Implementation Rule 7–3–2 3.14 return type must be int. 33 3.6.1(3) The linkage of main. Implementation Rule 7–3–2 3.15

34 3.6.1(4) The library function exit is called to end a Undefined 2.11 program during the destruction of an object with static storage duration.

192 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 35 3.6.2(2) Whether an object is fully, or merely Unspecified 1.01 zero-initialized when an object refers to another object of namespace scope with static storage duration potentially requiring dynamic initialization and defined later in the same translational unit. 36 3.6.2(3) Whether the dynamic initialization of an Implementation 3.16 object of namespace scope is done before the first statement of main. 37 3.6.3(2) A function contains a local object of static Undefined 2.12 storage duration that has been destroyed and the function is called during the destruction of an object with static storage duration and the flow of control passes through the definition of the previously destroyed object. 38 3.7.3.1(2) The order, contiguity and initial value Unspecified 1.02 of storage allocated by the allocation functions. 39 3.7.3.1(2) The results of dereferencing a pointer Undefined 2.13 returned as a request for zero size space in a call to an allocation function. 40 3.7.3.2(4) Attempt to use a pointer to a deleted Undefined 2.14 object. 41 3.8(4) The side effects of a non-trivial destructor Undefined 2.15 of an object of class type whose lifetime has ended, but whose destructor has not been called explicitly. 42 3.8(5) An object will be or was of a class type Undefined 2.16 with a non-trivial destructor and the pointer is used as the operand of a delete- expression. 43 3.8(5) Series of uses of a pointer to a non- Undefined 2.17 POD class type between object storage allocation and the start of object lifetime, and the end of object lifetime and storage de-allocation. 44 3.8(6) An lvalue-to-rvalue conversion is applied Undefined 2.18 to an lvalue that refers to an object whose lifetime has not yet started but whose storage has been allocated, or whose lifetime has ended but whose storage has not been reused or released. 45 3.8(6) Series of uses of an lvalue that refers to a Undefined 2.19 non-POD class type between object storage allocation and the start of object lifetime, and the end of object lifetime and storage deallocation.

193 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 46 3.8(8) A program ends the lifetime of an object Undefined 2.20 of type T with static or automatic storage duration, T has a non-trivial destructor and an object of a different type occupies the storage location when the implicit destructor call takes place. 47 3.8(9) A new object is created at the storage Undefined 2.21 location that a const object with static or automatic storage duration occupies or, at the storage location that such a const object used to occupy before its lifetime ended. 48 3.9(4) For POD types, the set of values of which Implementation Rule 9–5–1 3.17 the value representation (a set of bits in the object representation that determines a value) is one discrete element. 49 3.9(5) The packing needed between sub-objects Implementation Rule 9–5–1 3.18 to meet alignment requirements 50 3.9.1(1) Whether char is equivalent to unsigned Implementation Rule 3–9–2 3.19 char or signed char. Rule 5–0–11 Rule 5–0–12 51 3.9.1(2) Size of int. Implementation 3.20

52 3.9.1(5) Type of wchar_t. Implementation Rule 3–9–2 3.21

53 3.9.1(8) The value representation of floating-point Implementation Rule 3–9–3 3.22 types. 54 3.9.2(3) The value representation of pointer types. Implementation 3.23

55 4.1(1) An lvalue, which does not refer to an Undefined 2.23 object of type T or is uninitialized, is used where an rvalue of type T is expected. 56 4.7(3) The value of a signed integer type due to Implementation 3.24 the conversion from either an integer or an enumeration type when the value cannot be represented in the destination type. 57 4.8(1) A floating-point conversion produces a Undefined 2.24 result that cannot be represented in the space provided. 58 4.8(1) The value resulting from converting a Implementation 3.25 value of a floating point type to another floating point type that cannot exactly represent the original value. 59 4.9(1) A floating-integral conversion produces Undefined Rule 5–0–5 2.25 a result that cannot be represented in the Rule 5–0–6 space provided. 60 4.9(2) The choice of either the next higher or Implementation 3.26 lower representable value when an rvalue of an integer or enumeration type is converted to an rvalue of a floating-point type but exact conversion is not possible.

194 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 61 5(4) The order of evaluation of operands of Unspecified Rule 5–0–1 1.03 individual operators and sub-expressions of individual expressions, and the order in which side effects take place. 62 5(4) An object is modified more than once or Undefined Rule 5–0–1 2.26 is modified and accessed other than to determine the new value, between two sequence points. 63 5(5) An arithmetic operation is invalid (such as Undefined 2.27 division or modulus by zero) or produces a result that cannot be represented in the space provided (such as overflow or underflow). 64 5.1(2) Pointers are compared using an equality Unspecified 1.14 operator and either is a pointer to a virtual member function. 65 5.2.2(1) A function is called through an expression Undefined 2.28 whose function type has a language linkage that is different from the language linkage of the function type of the called function’s definition. 66 5.2.2(7) An argument with no parameter, after Undefined Rule 8–4–1 2.29 standard conversions, has a non-POD class type. 67 5.2.2(8) The order of evaluation of arguments in a Unspecified 1.04 function call and the order of evaluation of the postfix expression and the argument expression list. 68 5.2.8(1) Whether or not the destructor is called Unspecified 1.05 for the type_info object at the end of the program. 69 5.2.8(1) The class (name) derived from std::type_ Implementation 3.27 info of an lvalue of dynamic type constname, that is the result of a typeid expression. 70 5.2.9(5) A static_cast is used to cast an lvalue of Undefined Rule 5–2–2 2.30 class type to a non-derived class. 71 5.2.9(7) An integer type is explicitly converted to Unspecified 1.06 an enumeration type but the integral value is not within the range of the enumeration values 72 5.2.9(8) A static_cast is used to cast a pointer of Undefined Rule 5–2–2 2.31 class type to a pointer from a non-derived class. 73 5.2.9(9) A static_cast is used to cast a pointer to a Undefined 2.32 class member to a pointer to a member of a non-derived class 74 5.2.10(3) The mapping performed by reinterpret_ Implementation 3.28 cast.

195 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 75 5.2.10(4) The mapping function used to explicitly Implementation Rule 5–2–9 3.29 converting a pointer to any integral type large enough to hold it. 76 5.2.10(5) Mappings between pointers and integers Implementation Rule 5–2–9 3.30 other than when a value of integral or enumeration type is explicitly converted into a pointer or when a pointer is converted to an integer of sufficient size and back to the same pointer type. 77 5.2.10(6) A pointer to a function is explicitly Unspecified Rule 5–2–6 1.07 converted to a function of a different type using reinterpret_cast. 78 5.2.10(6) A pointer to a function is converted by Undefined Rule 5–2–6 2.33 reinterpret_cast to point to a function of a different type and used to call a function of a type not compatible with the original type. 79 5.2.10(7) A pointer to an object is explicitly Unspecified Rule 5–2–7 1.08 converted to a pointer to an object of a Rule 5–2–8 different type using reinterpret_cast. 80 5.2.10(9) A pointer to member of some type is Unspecified 1.09 explicitly converted to a pointer to another member of another type using reinterpret_ cast. 81 5.2.11(12) The use of values produced from Undefined 2.35 conversions between pointers and functions, pointers and member functions and in particular a pointer to a const member function to a pointer to a non- const member function. 82 5.2.11(7) Depending on the type of object, a write Undefined 2.34 operation through the pointer, lvalue or pointer to data member resulting from a const_char that casts away a const-qualifier may produce undefined behaviour. 83 5.3.1(4) The address of an object with incomplete Undefined Rule 5–3–3 2.36 type, whose complete type declares operator&() as a member function. 84 5.3.3(1) The result of sizeof applied to any Implementation 3.31 fundamental type (other than char, signed char and unsigned char), in particular sizeof(bool) and sizeof(wchar_t). 85 5.3.4(15) The value of a POD object created by a Indeterminate 4.02 new-expression when a new-initializer is omitted. 86 5.3.4(21) The order of evaluation of the allocation Unspecified 1.10 function and its arguments. 87 5.3.4(21) The evaluation of arguments if the Unspecified 1.11 allocation function returns null or exits using an exception.

196 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 88 5.3.4(6) The first array dimension applied to a new Undefined 2.37 operator is negative. 89 5.3.5(2) The behaviour of the delete operator on a Undefined 2.38 pointer to a non-array object or a pointer to a sub-object representing the base class of such an object that was not obtained from a new operator. 90 5.3.5(2) The value of the operand of delete is Undefined 2.39 not the pointer value that resulted from a previous array new-expression when deleting an array. 91 5.3.5(3) When deleting an object and the static Undefined 2.40 type of the operand is different from its dynamic type and either the static type is not a base class of the operand’s dynamic type, or the static type does not have a virtual destructor. 92 5.3.5(3) The dynamic type of the object to be Undefined 2.41 deleted differs from its static type when deleting an array. 93 5.3.5(4) The value of a pointer that refers to Indeterminate 4.03 deallocated storage 94 5.3.5(5) The object being deleted has incomplete Undefined 2.42 class type at the point of deletion and the complete class has a non-trivial destructor or deallocation function. 95 5.4(6) Whether the static_cast or reinterpret_cast Unspecified 1.12 interpretation is used if either the operand or destination type of the cast is a pointer to incomplete class type. 96 5.5(4) In a pointer-to-member operation the Undefined 2.43 dynamic type of an object does not contain the member to which the pointer refers. 97 5.5(6) The second operand of an ->* expression is Undefined 2.44 the null pointer to a member value. 98 5.6(4) The second operand of the / or % operators Undefined 2.45 is zero. 99 5.6(4) The sign of the remainder using the binary Implementation Rule 1–0–3 3.32 % operator unless both operands are non- negative. 100 5.7(5) A pointer that does not behave like a Undefined Rule 5–0–16 2.46 pointer to an element of an array object is added to or subtracted from. 101 5.7(5) The resultant pointer from an addition or Undefined Rule 5–0–16 2.47 subtraction to a pointer to an element of an array which does not point within the array (or one beyond). 102 5.7(6) Two pointers to elements of the same array Undefined 2.48 object are subtracted, the result does not fit in the space provided and there is an arithmetic overflow.

197 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 103 5.7(6) Pointers that do not behave like pointers to Undefined Rule 5–0–17 2.49 elements of the same array are subtracted. 104 5.7(6) The signed integral type given as a result Implementation 3.33 of the subtraction of two pointers to elements of the same array object. 105 5.8(1) An expression is shifted by a negative Undefined Rule 5–8–1 2.50 number or by an amount greater than or equal to the width in bits of the expression being shifted. 106 5.8(3) The value given as a result of >> shift Implementation Rule 5–0–21 3.34 operator where the shift-expression has a signed type and is negative 107 5.9(2) Pointers are compared using a relational Unspecified 1.13 operator that do not point to members of the same object, elements of the same array or to the same functions, etc… 108 5.17(8) An object is assigned to an overlapping Undefined Rule 0–2–1 2.51 object. 109 6.6.3(2) The effect of flowing off the end of a Undefined Rule 8–4–3 2.52 function that is expected to return a value 110 6.7(4) Control re-enters a declaration recursively Undefined 2.53 while an object is being initialized. 111 6.8(3) During parsing, a name in a template Behaviour that 5.07 parameter is bound differently than it requires no would be bound during a trial parse. diagnostics 112 7.1.5.1(4) An attempt is made to modify a const Undefined Rule 5–2–5 2.54 object, other than any class member declared mutable. 113 7.1.5.1(7) An attempt is made to refer an object Undefined Rule 5–2–5 2.55 defined with volatile-qualified type through the use of an lvalue with non-volatile- qualified type. 114 7.1.5.2(1) Whether bit-fields and objects of char Implementation Rule 5–0–11 3.35 type are represented as signed or unsigned Rule 5–0–12 quantities. Rule 9–6–2 115 7.2(4) The type of an uninitialized first Unspecified 1.15 enumerator. 116 7.2(4) The value of an uninitialized enumerator Unspecified 1.16 is not representable in the type of the preceding enumerator. 117 7.2(5) The integral type used as the underlying Implementation 3.36 type for an enumeration. 118 7.2(9) A value is not in the range of the Unspecified Rule 7–2–1 1.17 enumeration type to which it is explicitly converted. 119 7.3.2(4) A namespace-name defined at global scope Behaviour that 5.08 is also declared as the name of another requires no entity in any global scope of the program. diagnostics 120 7.4(1) The meaning of an asm declaration. Implementation Rule 7–4–1 3.37

198 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 121 7.5(1) Implementation specific properties Implementation Rule 1–0–2 3.38 associated with an entity with language linkage 122 7.5(2) The meaning of the string-literal in a Implementation Rule 1–0–2 3.39 linkage-specification 123 7.5(2) The spelling of the language’s name when Implementation Rule 1–0–2 3.40 the string-literal in a linkage-specification names a programming language 124 7.5(2) The semantics of a language linkage other Implementation Rule 1–0–2 3.41 than C++ or C. 125 7.5(9) Linkage from C++ to objects defined in Implementation Rule 1–0–2 3.42 other languages and to objects defined in C++ from other languages. 126 8.3.2(3) Whether a reference requires storage. Unspecified 1.18 127 8.3.2(4) Dereferencing a null pointer. Undefined 2.56 128 8.3.6(9) The order of evaluation of function Unspecified 1.19 arguments. 129 8.5(9) The value of an object if no initializer is Indeterminate Rule 8–5–1 4.04 specified. 130 8.5.3(8) How the reference is bound when a Implementation 3.43 reference to type “cv1 T1” is initialized by an expression “cv2 T2”. 131 9.2(12) The order of allocation of non-static data Unspecified 1.20 members separated by an access-specifier 132 9.3.1(1) A member function of a class X is called Undefined 2.57 for an object that is not of type X or a type derived from X. 133 9.6(1) The allocation of bit-fields within a class. Implementation Rule 9–6–1 3.44

134 9.6(3) Whether a plain (neither explicitly signed Implementation Rule 9–6–2 3.46 nor unsigned) char, short, int or long bit- field is signed or unsigned. 135 9.6(4) Alignment of bit-fields Implementation 3.45

136 10(3) The order in which the base class Unspecified 1.21 subobjects are allocated in the most derived object 137 10.3(8) A virtual function declared in a class is Behaviour that 5.09 both defined and declared pure in that requires no class. diagnostics 138 10.4(6) A virtual call is made from a constructor Undefined Rule 12–1–1 2.58 (or destructor) of an abstract class to a pure virtual function directly or indirectly for the object being created (or destroyed). 139 11.1(2) The order of allocation of data members Unspecified 1.22 with separate access-specifier labels

199 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 140 12.1(15) The value of an object obtained, if during Unspecified 1.23 the construction of a const object, the object is accessed through an lvalue not obtained from the constructor’s this pointer. 141 12.2(5) The order of creation of temporary objects. Unspecified 1.24 142 12.4(12) A destructor is invoked for an object that Undefined 2.59 is not of the destructor’s class or not of a class derived from the destructor’s class. 143 12.4(14) A destructor is invoked for an object whose Undefined 2.60 lifetime has ended 144 12.6.2(4) The value of a member of a class if it is not Indeterminate 4.05 otherwise initialized by the constructor. 145 12.6.2(8) A member function (including virtual Undefined 2.61 member functions) is called for an object under construction, or an object under construction is used as the operand of the typeid operator or of a dynamic_cast performed in a ctor-initializer (or a function called directly or indirectly from a ctor-initializer) before all of the mem- initializers for base classes have been completed. 146 12.7(1) Referring to any nonstatic member or base Undefined 2.62 class of an object of non-POD class type, before the constructor begins execution and after the destructor finishes execution. 147 12.7(2) Converting a pointer to an object of class Undefined 2.63 X to a direct or indirect base class of X, where the construction of the object has not started or the destruction of the object has completed. 148 12.7(2) Forming a pointer to (or access the value Undefined 2.64 of) a direct nonstatic member of an object, where the construction of the object has not started or the destruction of the object has completed. 149 12.7(3) The result of making a virtual call using Undefined 2.65 an explicit class member access and the object expression refers to the object under construction or destruction but its type is neither the constructor or destructor’s own class or one of its bases. 150 12.7(4) The operand of typeid refers to an object Undefined 2.66 under construction or destruction and the static type of the operand is neither the constructor or destructor’s class nor one of its bases.

200 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 151 12.7(5) If the operand of the dynamic_cast refers to Undefined 2.67 the object under construction or destruction and the static type of the operand is not a pointer to or object of the constructor is not a pointer to or object of the constructor or destructor’s own class or one of its bases. 152 12.8(13) Whether sub-objects representing virtual Unspecified 1.25 base classes are assigned more than once by the implicitly-defined copy assignment operator. 153 12.8(4) Any use of a user defined copy constructor Behaviour that 5.10 that matches the implicitly declared copy requires no constructor diagnostics 154 14(4) The linkage of a template, a template Implementation 3.47 explicit specialization or a class template partial specialization, if it is something other than C or C++. 155 14(8) A template that is exported more than once Behaviour that 5.11 in a program. requires no diagnostics 156 14(8) A non-exported template which is neither Behaviour that 5.12 defined in every translation unit in which requires no it is implicitly instantiated nor explicitly diagnostics instantiated in some translation unit 157 14.3.3(2) A specialization is not visible at the point Behaviour that 5.13 of instantiation, and it would have been requires no selected had it been visible. diagnostics 158 14.5.4(1) A partial specialization of a template Behaviour that Rule 14–7–3 5.14 is not declared before its first use that requires no would cause implicit instantiation in any diagnostics translation unit. 159 14.5.5.1(7) A program contains declarations of Behaviour that 5.15 function templates that are functionally requires no equivalent but not equivalent. diagnostics 160 14.6(7) No valid specialization can be generated Behaviour that 5.16 for a template definition, but the template requires no is not instantiated. diagnostics 161 14.6.4.1(7) Two different points of instantiation give a Behaviour that Rule 14–7–3 5.17 template specialization different meanings requires no according to the one definition rule. diagnostics 162 14.6.4.2(1) If a function call that depends on a Undefined 2.68 template parameter would be ill-formed or would find a better match had the lookup within the associated namespaces considered all the function declarations with external linkage introduced with those namespaces in all translation units 163 14.7.1(14) The instantiation of a template produces Undefined 2.69 recursion beyond some defined limit 164 14.7.1(14) The limit on the total depth of recursive Implementation 3.48 instantiation of templates

201 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 165 14.7.1(5) Whether the instantiation occurs when the Unspecified 1.26 overload resolution process can determine the correct function to call without instantiating a class template definition. 166 14.7.1(9) Whether an implementation implicitly Unspecified 1.27 instantiates a virtual member function of a class template if the virtual member function would not otherwise be instantiated. 167 14.7.3(6) An explicit specialization of a template Behaviour that Rule 14–7–3 5.18 is not declared before its first use in requires no any translation unit that causes implicit diagnostics instantiation 168 15.1(4) The way memory is allocated for the Unspecified 1.28 temporary copy of an exception being thrown 169 15.1(4) Deallocation of memory for a temporary Unspecified 1.29 object when the last handler exits by any means other than a throw and the temporary object is then destroyed. 170 15.3(10) Referring to any non-static member or Undefined Rule 15–3–3 2.70 base class of an object in the handler for a function-try-block of a constructor or destructor for that object. 171 15.3(16) Flowing off the end of a function-try-block Undefined 2.71 in a value returning function. 172 15.3(9) Whether or not the stack is unwound Implementation Rule 15–1–3 3.49 before the call to terminate(), in the case Rule 15–3–1 where no matching handler is found in a Rule 15–3–2 program. Rule 15–3–4 Rule 15–5–1 173 15.4(2) Sets of type-ids in exception-specifications Behaviour that Rule 15–4–1 5.19 in two translation units differ. requires no diagnostics 174 15.5.2(2) The object of type std::bad_exception that Implementation 3.50 is used to replace an exception thrown or re-thrown by the unexpected() function that the exception-specification does not allow. 175 16.1(4) The token defined is generated during the Undefined 2.72 expansion of a #if or #elif pre-processing directive. 176 16.1(4) The #defined pre-processing directive does Undefined Rule 16–1–1 2.73 not match one of the two specified forms. 177 16.1(4) Whether the value of an interpreted Implementation 3.51 character literal matches the value obtained when an identical character literal occurs in an expression. 178 16.1(4) Whether a single-character character literal Implementation 3.52 may have a negative value.

202 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 179 16.2(2) The sequence of places searched for the Implementation 3.53 header file specified between the < and > delimiters due to a #include new-line pre-processing directive. 180 16.2(2) During execution of a #include pre- Implementation 3.54 processor directive, how the places are searched and how the header file is identified. 181 16.2(3) The sequence of places searched for the Implementation 3.55 header file specified in quotes in a #include "q-char-sequence" new-line pre-processing directive. 182 16.2(4) The #include pre-processing directive that Undefined Rule 16–2–6 2.74 results after expansion does not match one of the header name forms. 183 16.2(4) The method by which a sequence of pre- Implementation 3.56 processing tokens between < and > or a pair of " characters is combined into a single header name pre-processing token. 184 16.2(5) The mapping between the delimited Implementation 3.57 sequence and the external source file name. 185 16.2(6) The nesting limit to which an #include pre- Implementation 3.58 processing directive may appear due to the #include directive of another file. 186 16.3(10) A function-like macro argument consists of Undefined Rule 16–0–4 2.75 no pre-processing tokens. 187 16.3(10) There are sequences of pre-processing Undefined Rule 16–0–5 2.76 tokens within the list of function-like macro arguments that would otherwise act as pre-processing directive lines. 188 16.3.2(2) The order of evaluation of # and ## Unspecified Rule 16–3–1 1.30 operators. Rule 16–3–2 189 16.3.2(2) The result of the pre-processing operator # Undefined Rule 16–3–1 2.77 is not a valid character string literal. Rule 16–3–2 190 16.3.3(3) The order of evaluation of ## operators. Unspecified Rule 16–3–1 1.31 Rule 16–3–2 191 16.3.3(3) The result of the pre-processing Undefined Rule 16–3–1 2.78 concatenation operator ## is not a valid Rule 16–3–2 pre-processing token. 192 16.4(3) The #line pre-processing directive specifies Undefined 2.79 zero or a number greater than 32767. 193 16.4(5) The #line pre-processing directive that Undefined 2.80 results after expansion does not match one of the two well-defined forms. 194 16.6(1) The behaviour of the implementation due Implementation Rule 16–6–1 3.59 to the #pragma pre-processing directive. 195 16.8(1) The date/time supplied, as a result of the Implementation 3.60 __DATE__ macro, if the date of translation is not available.

203 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix B (continued)

MISRA ISO Description Category MISRA Source Id Reference Guidance Id 196 16.8(1) The date/time supplied, as a result of the Implementation 3.61 __TIME__ macro, if the time of translation is not available. 197 16.8(1) Whether __STDC__ is predefined and its Implementation 3.62 value. 198 16.8(3) One of the following identifiers is Undefined Rule 17–0–1 2.81 the subject of a #define or a #undef pre-processing directive. __LINE__, __FILE__, __DATE__, __TIME__, __STDC__, __cplusplus, or the identifier defined.

204 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix C Appendix C: Glossary

ADL ADL is an abbreviation for argument-dependent lookup. Aggregate An array is an aggregate. A class is an aggregate if all the following apply: • It has no user declared constructors; • It has no private or protected non-static data members; • It has no base classes; • It has no virtual functions. Associated namespace An associated namespace is an additional namespace that is searched during argument-dependent lookup. The set of associated namespaces is described in ISO/IEC 14882:2003 [1] §3.4.2(2). Callback A callback is a function that is called indirectly via a function pointer or a handle. Class-data The class-data for a class is all non-static member data and any resources acquired in the constructor or released in the destructor. Code Code consists of everything within a translation unit that is not excluded by conditional compilation. Note that code also includes any declarations and definitions that are introduced by the compiler (e.g. default constructors, etc). Compatible types Compatible types are types that, for the purpose of declaration matching, are treated as the same. Two identical types are compatible but two compatible types need not be identical. For example, short int and short are compatible. Dataflow anomaly The state of a variable at a point in a program can be described using the following terms: • Undefined (U): The value of the variable is indeterminate; • Referenced (R): The variable is used in some way (e.g. in an expression); • Defined (D): The variable is explicitly initialised or assigned a value. Given the above, the following dataflow anomalies can be defined: • UR dataflow anomaly: Variable not assigned a value before the specified use; • DU dataflow anomaly: Variable is assigned a value that is never subsequently used; • DD dataflow anomaly: Variable is assigned a value twice with no intermediate use. DD dataflow anomaly See dataflow anomaly.

205 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix C (continued)

Dead code Dead code (also known as redundant code) consists of evaluated expressions whose removal would not affect the output of a program. Declaration For the purposes of this standard, in headline rule text a declaration is the first introduction of a name into a translation unit. All subsequent “declarations” (as per ISO/IEC 14882:2003 [1] §3.2(1)) are re-declarations. A definition is also always either a declaration or re-declaration, but with the characteristics described in ISO/IEC 14882:2003 [1] §3.2(2). Definition See Declaration. DU dataflow anomaly See dataflow anomaly. Function set A function set is: • A function; • A function overload set. Generic function A function template or operator template that can be called without explicit template arguments and whose parameters are of built-in type or which are generic parameters. For example: template void f(T const & t);

Generic parameter A template type parameter T is a generic parameter if, in the function declaration, it has the (possibly cv-qualified) form . T &[opt] For example: T const & t T T volatile

Handle A handle is a variable that refers to a resource. Header file A header file is any file that is the subject of a #include directive. Note that the filename extension is not significant. Include guard An include guard is a construct used to avoid the problems associated with multiple inclusion when dealing with the #include directive.

206 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix C (continued)

Infeasible path Infeasible paths occur where there is a syntactic path to a code fragment, but the semantics ensure that the control flow path will not be executed. Example: if ( u32 < 0 ) { // An unsigned value will never be negative, // so code in this block will never be executed. }

LRM LRM is an abbreviation for Language Reference Manual. NDR NDR is an abbreviation for No Diagnostic Required. ODR ODR is an abbreviation for the One Definition Rule. POD POD is an abbreviation for Plain Old Data. A struct or union is POD if all the following apply: • It is an aggregate; • It has no non-static members with type non-POD (or array of non-POD); • It has no non-static members with type reference; • It has no user declared copy assignment operator; • It has no user declared destructor. A class is a POD if it is either a struct or a union that is a POD. Project A project consists of the code from the set of translation units used to build the application. Primary template The primary template is the first declaration of a template. Redundant code See Dead code. Re-declaration See Declaration. Resource A resource is an entity whose lifetime is controlled explicitly by the developer. The developer is therefore responsible for acquiring and relinquishing the resource.

207 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Appendix C (continued)

Unreachable code Unreachable code is code to which there is no syntactic (control flow) path, e.g. a function which is never called, either directly or indirectly. UR dataflow anomaly See dataflow anomaly. Use / used / using An object is used if it is: • The subject of a cast; • Explicitly initialized at declaration time; • An operand in an expression; • Referenced. Unique Within the rules, unique means that the associated text/rule applies across the whole project. Unused A type or object is unused if it is not used.

208 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1 ISBN 978-1-906400-03-3 paperback ISBN 978-1-906400-04-0 PDF

Licensed to: Insigma Rail Transport. Engineering Co. He Yulin. 12 Oct 2010. Copy 1 of 1