misra-cpp2008
misra c++编号规则
misra c++编号规则
MISRA C++ (MISRA C++:2008) 是一种针对C++ 编程语言的软件开发规范，旨在提高代码的可读性、可维护性和可靠性。
MISRA C++ 包含一系列规则，下面是一些常见的MISRA C++ 编号规则示例：
1. 规则2-1-1：禁止使用C 语言风格的强制类型转换。
2. 规则3-1-1：不允许使用多个返回语句。
3. 规则5-0-1：禁止使用C 语言风格的字符串操作函数。
4. 规则5-2-2：确保容器类的size() 函数返回无符号整数类型。
5. 规则8-0-1：不允许在头文件中定义非内联函数。
6. 规则14-0-1：确保每个函数都有明确的返回语句。
这些规则是为了遵循良好的编程实践和减少代码的潜在错误，但具体的规则数量和内容可能因不同版本的MISRA C++ 规范而有所不同。
在实际开发中，开发人员可以根据规范选择性地遵循相应的规则，并结合工具和代码审查等方法来确保代码符合MISRA C++ 规范的要求。
需要注意的是，MISRA C++ 规范是一种指导性的规范，可以帮助开发人员编写高质量、可靠的C++ 代码，但它并不适用于所有项目和情况。
在实际使用中，应根据项目需求和团队约定来决定是否采用MISRA C++ 规范以及具体遵循哪些规则。
MISRA--工业标准的C编程规范
ISR Guidelines For The Use Of TheC Language In Vehicle Based SoftwarePDF version 1.0© MIRA, 1998 This electronic version of the MISRA C Guidelines is issued solely for the use of member companies of the MISRA Consortium.MIRA grants permission for member companies to distribute this PDF file within their own companies. The file should not be altered in any way, nor should hard copies be made. No permission is given for use or distribution of this file by or to individuals or companies who are not members of the MISRA consortium, and 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, and the published paper document should be taken as authoritative. Information is available from the MISRA web site on how to obtain printed copies of the document.First published April 1998by The Motor Industry Research AssociationWatling StreetNuneatonWarwickshire CV10 0TU/© The Motor Industry Research Association, 1998.“MISRA” and the triangle logo are registered trademarks of The Motor Industry Research Association, 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.Available in paperback (ISBN 0 9524156 9 0)British Library Cataloguing in Publication Data.A catalogue record for this book is available from the British LibraryThe Motor Industry Software Reliability Association GuidelinesFor The UseOf TheC LanguageIn VehicleBasedSoftwareApril 1998(PDF version 1.0, July 1998)DisclaimerAdherence to the requirements of this document does not in itself ensure error-free robustsoftware or guarantee portability and re-use.Compliance with the requirements of this document, or any other standard, does not of itselfconfer immunity from legal obligations.Executive summaryThis document specifies a subset of the C programming language which is intended to be suitable for embedded automotive systems up to and including safety integrity level 3 (as defined in the MISRA Guidelines). It contains a list of rules concerning the use of the C programming language together with justifications and examples.In addition to these rules the document also briefly describes the reason why such a language subset is required and gives guidance on how to use it.It is recognised that these language issues are only a small part of the overall task of developing software, and guidance is given on what else needs to be addressed by the developer if they are to have a credible claim of ‘best practice’development.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 users have received the appropriate training and are competent C language programmers.AcknowledgementsThe MISRA consortium would like to thank the following individuals for their contribution to the writing of this document:Paul Edwards Rover Group LtdSimon Fisher AB Automotive Electronics LtdGavin McCall Visteon Automotive Systems, an enterprise of Ford Motor Company Ltd David Newman Visteon Automotive Systems, an enterprise of Ford Motor Company Ltd Frank O’Neill Lucas Automotive ElectronicsRichard Pearman Lotus EngineeringRoger Rivett Rover Group LtdThe MISRA consortium also wishes to acknowledge contributions from the following individuals during the review process:David Blyth D. C. Hurst Steve MontgomeryDave Bowen Peter Jesty Tim MortimerMark Bradbury Derek Jones Edward NelsonKwok Chan Ian Kendall Frank PlaggeShane Cook Andreas Krüger Agneta SjögrenFrank Cooper Lawrence Lane Kevin TalbotDewi Daniels Chris Leiby Chris TappGavin Finnie Thomas Maier Lloyd ThomasJohn Fox Paul Martin Ken TindellKenshiro Hashimoto Neil Martin Ron WilsonRichard Hathway M. A. C. Mettes Chris WintersSteven Hughes Charlie MonkThe reviewers represented a broad cross-section of automotive developers and component suppliers originating from eight countries (Austria, Germany, Japan, Holland, Norway, Sweden, United Kingdom and United States of America) and the following types of organisations:•Vehicle manufacturers (8)•Component and system suppliers (7)•Software specialists and consultancies (6)•Compiler and static analyser suppliers (3)•Research and development organisations (3)•Universities (4)ContentsPage 1. Background – the use of C and issues with it (1)1.1 The use of C in the automotive industry (1)1.2 Language insecurities and the C language (1)1.2.1 The programmer makes mistakes (1)1.2.2 The programmer misunderstands the language (2)1.2.3 The compiler doesn’t do what the programmer expects (2)1.2.4 The compiler contains errors (2)1.2.5 Run-time errors (3)1.3 The use of C for safety-related systems (3)1.4 C standardization (4)2. MISRA C: The vision (5)2.1 Rationale for the production of MISRA C (5)2.2 Objectives of MISRA C (5)3. MISRA C: Developing the subset (6)4. MISRA C: Scope (7)4.1 Base language issues (7)4.2 Issues not addressed (7)4.3 Applicability (7)4.4 Safety Integrity Level issues (7)4.5 Prerequisite knowledge (8)4.6 C++ issues (8)4.7 Auto-generated code issues (8)5. Using MISRA C (9)5.1 The software engineering context (9)5.2 The programming language and coding context (9)5.2.1 Training (10)5.2.2 Style guide (10)5.2.3 Tool selection and validation (10)5.2.4 Source complexity metrics (12)5.2.5 Test coverage (12)5.3 Adopting the subset (12)5.3.1 Compliance matrix (13)5.3.2 Deviation procedure (13)5.3.3 Formalisation within quality system (14)5.3.4 Introducing the subset (14)5.4 Claiming compliance (15)5.5 Continuous improvement (15)Contents (continued)Page 6. Introduction to the rules (16)6.1 Rule classification (16)6.1.1 Required rules (16)6.1.2 Advisory rules (16)6.2 Organisation of rules (16)6.3 Redundancy in the rules (16)6.4 Presentation of rules (17)6.5 Understanding the source references (18)6.5.1 Key to the source references (18)6.5.2 Understanding Annex G references (19)7. Rules (20)7.1 Environment (20)7.2 Character Sets (22)7.3 Comments (23)7.4 Identifiers (23)7.5 Types (24)7.6 Constants (26)7.7 Declarations and Definitions (27)7.8 Initialisation (29)7.9 Operators (31)7.10 Conversions (34)7.11 Expressions (35)7.12 Control Flow (39)7.13 Functions (42)7.14 Pre-processing Directives (46)7.15 Pointers and Arrays (50)7.16 Structures and Unions (51)7.17 Standard Libraries (53)8. References (58)Appendix A: Summary of rules (59)Appendix B: Cross references to the ISO standard (67)1.Background1. Background – the use of C and issues with it1.1 The use of C in the automotive industryThe C programming language [1] is growing in importance and use for real-time embedded applications within the automotive industry. 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:•For many of the microprocessors in use, if there is any other language available besides assembly language then it is usually C. In many cases other languages are simply notavailable for the hardware.•C gives good support for the high-speed, low-level, input/output operations, which are essential to many automotive embedded systems.•Increased complexity of applications makes the use of a high-level language more appropriate than assembly language.•C can generate smaller and less RAM-intensive code than many other high-level languages.•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 stagein a project lifecycle.•A growth in the use of auto-generated C code from modelling packages.•Increasing interest in open systems and hosted environments.1.2 Language insecurities and the C languageNo 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 categorised below. Examples are given to illustrate insecurities in the C language.1.2.1 The programmer makes mistakesProgrammers make errors, which can be as simple as mis-typing a variable name, or might involve something more complicated like 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 language 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.1.Background (continued)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 programmers know what they are doing, which can mean that if errors are made they are allowed to pass unnoticed by the language. An area in which C is particularly weak 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 integer that they are using to represent a true/false value. Most such mismatches are simply forced to become compatible. IfC is presented with a square peg and a round hole it doesn’t complain, but makes them fit!1.2.2 The programmer misunderstands the languageProgrammers can misunderstand the effect of constructs in a language. Some languages are more open to such misunderstandings than others.There are quite a number of areas of the C language that are easily misunderstood by programmers. An example is the set of rules for operator precedence. These rules are well defined, but very complicated, and it is easy to make the wrong assumptions about the precedence that the operators will take in a particular expression.1.2.3 The compiler doesn’t do what the programmer expectsIf a language has features that are not completely defined, or are ambiguous, then a programmer can assume one thing about the meaning of a construct, while the compiler can interpret it quite differently.There are many areas of the C language which 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. Altogether the C standard, in Annex G, lists 201 issues that may vary in this way. This can present a sizeable problem with the language, particularly when it comes to portability between compilers. However, in its favour, the C standard does at least list the issues, so they are known.1.2.4 The compiler contains errorsA 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 errorsA somewhat different language issue arises with code that has compiled correctly, but for reasons of the particular data supplied to it causes errors in the running 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 price 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 systemsIt 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 been expressed about the use of C on 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 as a language is the fact that C is very mature, and consequently well analysed and tried in practice. Therefore its deficiencies are known and understood. Also 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’).Hatton [2] considers that, providing “... severe and automatically enforceable constraints ...” are imposed, C can be used to write “... software of at least as high intrinsic quality and consistency as with other commonly used languages”.Nonetheless, it should be recognised that there are other languages available which are in general better suited to safety-related systems, having (for example) fewer insecurities and better type checking. Examples of languages generally recognised to be more suitable than C are Ada and Modula 2. If such languages could be available for a proposed system then their use should be seriously considered in preference to C.Note also 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 standardizationThe current full standard for the C programming language is ISO/IEC 9899:1990 [1] along with technical corrigendum 1 (1995), and this is the standard which has been adopted by this document. The standard is also published by BSI in the UK as BS EN 29899:1993 and Amendment 1.The same standard was originally published by ANSI as X3.159-1989 [3]. In content the ISO/IEC standard and the ANSI standard are identical, and equally acceptable for use with this document. Note, however, that the section numbering is different in the two standards, and this document follows the section numbering of the ISO standard.Also note that the ANSI standard [3] contains a useful appendix giving the rationale behind some of the decisions made by the standardization committee. This appendix does not appear in the ISO edition.2.The vision2. MISRA C: The vision2.1 Rationale for the production of MISRA CThe MISRA consortium published its Development Guidelines for Vehicle Based Software [4] in 1994. This document describes the full set of measures that should be used in software development. In particular, the choices of language, compiler and language features to be used, in relationship with integrity level, are recognised to be of major importance. Section 3.2.4.3 (b) and Table 3 of the MISRA Guidelines [4] address this. One of the measures recommended is the use of a subset of a standardized language, which is already established practice in the aerospace, nuclear and defence industries. This document addresses the definition of a suitable subset of C.2.2 Objectives of MISRA CIn publishing this document regarding the use of the C programming language, the MISRA consortium is not intending to promote the use of C in the automotive industry. Rather it recognises 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 both by vehicle manufacturers and the many component suppliers. 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 automotive embedded systems.Although much has been written by academics concerning languages and their pros and cons this information is not well known among automotive developers. Another goal of this document is that engineers and managers within the automotive industry will become much more aware of the language-choice issues.The availability of many tools to assist in the development of software, particularly tools to support the use of C, is a benefit. However there is always a concern over the robustness of their design and implementation, particularly when used for the development of safety-related software. It is hoped that the active approach of the automotive industry to establish software best practice (through the MISRA Guidelines [4] and this document) will encourage the commercial off-the-shelf (COTS) tool suppliers to be equally active in ensuring their products are suitable for application in the automotive industry.3.Developing the subset3. MISRA C: Developing the subsetThe list of rules for this document was developed in three main phases. Firstly, a survey was conducted of available source material; secondly, this information was filtered and adapted into rules; and thirdly, the resulting material was subject to expert review and revision.The initial information was collected from a variety of sources, both published and anecdotal. The aim at this stage was to collect as much information as possible on the concerns that people have with the C language and its ‘danger areas’. Published sources of information included:•The ‘portability’annex (Annex G) of the ISO C standard [1]•“Safer C” by Les Hatton [2]•“C Traps and Pitfalls” by Andrew Koenig [5]S tandards created in-house by member companies of the MISRA consortium were also collated to provide additional information based on experience. Finally, additional ideas were collected from individuals, course notes and other such sources.T his pool of gathered information provided, in some cases, direct ideas for rules, and in other cases issues or problems with the language or its use which ought to be addressed in some way. Thus the second stage, of producing the list of rules, involved filtering and refining existing rules, and developing rules to address other issues which were identified.A lthough there is no totally objective way of arriving at a given set of rules, the following principles were used to guide this stage of the process:•Issues of style were omitted, i.e. issues which were not believed to have any significant impact on code integrity, but which were more matters of preference.•As far as practicable, rules were to be enforceable by static tools. In some cases, however, rules which are not statically enforceable were retained because the advicethey give needs to be heeded by the programmer.4.Scope4. MISRA C: Scope4.1 Base language issuesThe MISRA Guidelines [4] (Table 3) requires that “a restricted subset of a standardized structured language” be used. For C, this means that the language must only be used as defined in the ISO standard. This therefore precludes the use of:•K&R C (as defined in the First Edition of “The C Programming language” by Kernighan and Ritchie)•C++•Proprietary extensions to the C language4.2 Issues not addressedIssues 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. What is important is not the exact style guidelines adopted by a user, or the particular metrics used, but rather that the user defines style guidelines and appropriate metrics and limits (see sections 5.2.2 and 5.2.4).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 tool set enforces the rules adequately.4.3 ApplicabilityThis document is designed to be applied to production code in automotive embedded systems.In terms of the execution environments defined by ISO 9899 [1] (section 5.1.2), this document is aimed at a ‘free-standing environment’, although it also addresses library issues since some standard libraries will often be supplied with an embedded compiler.Most of the requirements of this document may be applicable to embedded systems in other sectors if such use is considered appropriate. The requirements of this document will not necessarily be applicable to hosted systems.It is also not necessary to apply the rules in full when performing compiler and static tool benchmarking. Sometimes it will be necessary to deliberately break the rules when benchmarking tools, so as to measure the tools’responses.4.4 Safety Integrity Level issuesThis document requires that all its provisions shall be adopted in systems classified as Integrity Levels 2 or 3 as defined in the MISRA Guidelines [4] (Debilitating or Difficult to control).4.Scope (continued)To be consistent with the MISRA Guidelines [4] (3.2.4.3b), no recommendations are made at this time for Integrity Level 4 (Uncontrollable).4.5 Prerequisite knowledgeThis 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 users have received appropriate training and are competent C language programmers.4.6 C++ issuesC++ is a different language to C, and the scope of this document does not include the C++ language, nor does it attempt to comment on the suitability or otherwise of C++ for programming safety-related systems. However the following comments about the use of C++ compilers and code should be noted.C++ is not simply a super-set of C (i.e. C plus extra features). There are a few specific constructs which have different interpretations in C and C++. In addition, valid C code may contain identifiers which in C++ would be interpreted as reserved words. For both of these reasons, code written in C and conforming to the ISO C standard will not necessarily compile under a C++ compiler with the same results as under a true C compiler. Thus the use of C++ compilers for compiling C code is deprecated by this document. If, for reasons of availability, a C++ compiler must be used to compile C code then the areas of difference between the two languages must first be fully understood.However, the use of additional compilers as extra static checking tools is encouraged. For this purpose, where the executable code is of no interest, C++ compilers may be used, and indeed can offer benefits because of the greater type checking they have over C.Where a compiler which is marketed as ‘C++’has a strictly conforming ISO C mode of operation then this is equivalent to a C compiler and may be used as such (in the C mode only). The same is true of any other tool which includes a conforming ISO C compiler as part of its functionality.C++ comments should not be used in C code. Although many C compilers support this form of comment (denoted by //), they are not a part of ISO standard C (see Rule 1).4.7 Auto-generated code issuesIf 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 [6].No judgement on the suitability of auto-code generation for MISRA Integrity Levels 2 and 3 should be implied by the inclusion of the topic within this document. Auto-generated code must be treated in just the same manner as manually produced code for the purpose of validation (See MISRA Guidelines [4] 3.1.3, Planning for V&V).ing MISRA C5. Using MISRA C5.1 The software engineering contextUsing a programming language to produce source code is just 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 [4] and, for example, include:•Documented development process•Quality system capable of meeting the requirements of ISO9001/ISO9000-3/TickIT [7,8,9]•Project management•Configuration management•Hazard analysis•Requirements•Design•Coding•Verification•ValidationIt 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 safety integrity level of the system.5.2 The programming language and coding contextWithin the coding phase of the software development process, the language subset is just 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 coverageAll decisions made on these issues need to be documented, along with the reasons for those decisions, and appropriate records should be kept for any activities performed. Such documentation may then be included in a safety justification if required.5.2.1 TrainingIn 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:•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 subset5.2.2 Style guideIn addition to adopting the subset, an organisation should also have an in-house style guide. This will contain guidance on issues which 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 likely to be subjective. Typical issues to be addressed by a style guide include:•code layout and use of indenting•layout of braces ‘{ }’and block structures•statement complexity•naming conventions•use of comment statements•inclusion of company name, copyright notice and other standard file header informationWhile 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 [10].5.2.3 Tool selection and validationWhen 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 Annex G.3 of the ISO standard [1]) then the developer must benchmark the compiler to establish that the implementation is as documented by the compiler writer. See section 6.5.2 for more explanation of Annex G.。
MISRA-C编程规范的介绍
“＝＝”误写成“＝”的错误，编译器可能不会认为 if （x＝y）
是一个程序员的失误。 再举个例子，大家都知道＋＋运算符。假如有下面的指令： i＝3； printf（“％d”，++i）；
随着很多汽车厂商开始接受 MISRA-C 编程规范，MISRA-C：1998 也成为汽车工业中最为著名的有关 安全性的 C 语言规范。2004 年，MISRA 出版了该规范的新版本——MISRA-C：2004。在新版本中，还 将面向的对象由汽车工业扩大到所有的高安全性要求系统。在 MISRA-C：2004 中，共有强制规则 121 条，推荐规则 20 条，并删除了 15 条旧规则。任何符合 MISRA-C：2004 编程规范的代码都应该严格的 遵守 121 条强制规则的要求，并应该在条件允许的情况下尽可能符合 20 条推荐规则。
输出应该是多少？如果是： printf（“％d”，i++）；
呢？如果改成-i++呢？i++++呢？i+++++i 呢？绝大多数程序员恐怕已经糊涂了。在 MISRA-C：2004 中，会明确指出++或--运算符不得和其他运算符混合使用。
C 语言非常灵活，它给程序员非常大的自由。但事情有好有坏，自由越大，犯错误的机会也就越多。 如果说有些错误是程序员无心之失的话，那么因为程序员对 C 语言本身或是编译器特性的误解而造成 的错误就是“明”知故犯了。C 语言有一些概念很难掌握，非常容易造成误解，如表达式的计算。请看下 面这条语句： if （ishigh && (x==i++)） 很多程序员认为执行了这条指令后，i 变量的值会自动加 1。但真正的情况如何呢？MISRA 中有一条规则： 逻辑运算符&&或||的右操作数不得带有副作用（side effect）（所谓带有副作用，就是指执行某条语 句时会改变运行环境，如执行 x=i++之后，i 的值会发生变化），就是为了避免这种情况下可能出现的问 题。 另外，不同编译器对同一语句的处理可能是不一样的。例如整型变量的长度，不同编译器的规定就不 同。这就要求程序员不仅要清楚 C 语言本身的特性，还要了解所用的编译器，难度很大。 还有些错误是由编译器（或者说编写编译器的程序员）本身造成的。这些错误往往很难发现，有可能 会移植存留在最后的程序中。 运行错误指得是那些在运行时出现的错误，如除数等于零，指针地址无效等问题。运行错误在语法检 查时一般无法发现，但一旦发生很可能导致系统崩溃。例如： #define NULL 0 …… char *p; p=NULL; printf(“Location of 0 is %d\n,*p); 语法上没有任何问题，但在某些系统上却可能运行出错。 C 语言可以产生非常紧凑、高效的代码，一个原因就是 C 语言提供的运行错误检查功能很少，虽然运 行效率得以提高，但也降低了系统的安全性。 有句话说得好，“正确的观念重于一切”。MISRA-C 规范对嵌入式程序员来讲，一个很重要的意义就 是提供给他们一些建议，让他们逐渐树立一些好的编程习惯和编程思路，慢慢摒弃那些可能存在风险的编 程行为，编写出更安全、健壮的代码。比如，很多嵌入式程序员都会忽略注释的重要性，但这样的做法会 降低程序的可读性，也会给将来的维护和移植带来风险。嵌入式程序员经常要接触到各种的编译器，而很 多 C 程序在不同的编译器下的处理是不一样的。MISRA-C：2004 有一条强制规则，要求程序员把所有和 编译器特性相关的 C 语言记录下来。这样在程序员做移植工作时，风险就降低了。
学习MISRAC之三：指针结构体联合体的安全规范
学习MISRAC之三：指针结构体联合体的安全规范学习MISRA C之三:指针结构体联合体的安全规范指针赋予了C编程最大的灵活性;结构体使得C程序整齐而紧凑;联合体在某些要求注重效率的场合有精彩的表现.这三个要素是C语言的精华.然而精华并不意味着完美。
C语言在赋予程序员足够的灵活性的同时，也给了程序员许多犯错的机会。
所以，有必要关注指针，结构体和联合体的实现细节，从而保障程序的安全性。
在此，第一部分介绍MISRA-C:2004中与指针相关的部分规则，第二部分讲解结构体和联合体的操作规范。
下文凡是未加特别说明的都是强制(required)规则，个别推荐(advisory)规则则加了“推荐”的提示.1.指针的安全规范MISRA-C:2004关于指针的规范主要分为三个部分：指针的类型转换规则,指针运算的规则和指针的有效性规则。
1.1 指针的类型转换指针类型转换是个高风险的操作，所以应该尽量避免进行这个操作。
MISRA-C对其中可能造成严重错误的情况做了严格的限定，选择其中两条做简要分析。
规则11.4(推荐) 指向不同数据类型的指针之间不能相互转化。
考察下面的程序uint8_t * p1;uint32_t * p2;p2 = (uint32_t *)p1;/* 注: uint8_t 表示8位无符号整型，uint32_t 表示32位无符号整型 */程序员希望将从p1单元开始的4个字节组成一个32位的整型来参与运算.如果CPU允许各种数据对象存放在任意的存储单元，则以上转换没有问题。
但某些CPU对某些(种)数据类型加强了对齐限制，要求这些数据对象占用一定的地址空间，比如某些字节寻址的CPU会要求32位（4字节)整型存放在4的整数倍地址上(也就是所谓的address a lighment地址对齐).在这个前提下,思考程序中的指针转化，假设p1一开始指向的是0x0003单元(对uint8_t型的整数没有对齐要求),则执行最后一行强制转换后，p2到底指向哪个单元就无法预料了.规则11.5 指针转换过程中不允许丢失指针的const，volatile属性按照如下定义指针uint16_t x;uint16_t * const cpi = &x; /* const 指针 */unit16_t * const *pcpi ; /* 指向const指针的指针 */const uint16_t * *ppci ; /* 指向const整数指针的指针 */ uint16_t * * ppi;const uint16_t * pci; /* 指向const整型的指针 */volatile uint16_t * pvi; /* 指向volatile整型的指针 */unit16_t *pi;则一下指针转换是允许的pi = cpi;以下指针转换是不允许的pi = (uint16_t *) pci;pi = (uint16_t *) pvi;ppi = (uint16_t **)pcpi;ppi = (uint16_t **)ppci;以上非法指针类型转换将会丢失const 或者 volatile 类型。
misra c 笔记2
60 The right hand operand of a logical && or || operator shall not contain side effects. 如下面的代码不是允许的：[cpp]view plain copy1.if ( ( a == 3 ) && b++ )2.{3. c = 1;4. }5.if ( ( a == 3 ) || b++ )6. {7. c = 1;8. }9.if ( ( a == 3 ) || func33 ( ) )10. {11. c = 1;12.}61 The operands of a logical && or || shall be primary-expressions.用”()” 显示说明每一个优先级.62 The operands of logical operators (&&, || and !) should be effectively Boolean. Expressions that are effectively Boolean should not be used as operands to operators other than (&&, || and !).63 bitwise operators shall not be applied to exprands whose underlying type is signed64 The right hand operand of a shift operator shall lie between zero and one less than the width inbits of the underlying type of the left hand operand.65 The unary minus operator shall not be applied to an expression whose underlying type is unsigned.66 The comma operator shall not be used.67 Evaluation of constant unsigned integer expressions should not lead towrap-around.68 The underlying bit representations of floatingpoint values shall not be used.69 The increment (++) and decrement (--) operators should not be mixed with other operators in anexpression.经常在网上或书上看到类似于下面的题目:x = y+++z; x = ?看到misra-c标准后, 我不由的感叹:这个世界还有很多有意义的事等着我们程序员去做.70 Assignment operators shall not be used in expressions that yield a Boolean value 如:[cpp]view plain copy1.if ( ( a = b ) != 0 )2. {3. c = 1;4. }71 Tests of a value against zero should be made explicit, unless the operand is effectively Boolean.72 Floating-point expressions shall not be tested for equality or inequality.73 The controlling expression of a for statement shall not contain any objects of floating type.74 The three expressions of a for statement shall be concerned only with loop control75 Numeric variables being used within a for loop for iteration counting shall not be modified in thebody of the loop.76 Boolean operations whose results are invariant shall not be permitted.77 There shall be no unreachable code.78 All non-null statements shall either :a) have at least one side-effect howeverexecuted, orb) cause control flow to change.79 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.78和79的意思是非空语句必须要么产生副作用( side-effect) (副作用是指表达式执行后对程序运行环境造成的影响。
软件编程规范（MISRA_C）
软件编程规范（MISRA_C）软件编程规范目录一环境二语言扩展三文档四字符集五标识符六类型七常量八声明与定义九初始化十数值类型转换十一指针类型转换十二表达式十三控制语句表达式十四控制流十五 switch语句十六函数十七指针和数组十八结构与联合十九预处理指令二十标准库二十一运行时错误一环境规则 1.1（强制）：所有代码都必须遵照ISO 9899:1990 “Programming languages - C”，由ISO/IEC 9899/COR1:1995，ISO/IEC 9899/AMD1:1995，和ISO/IEC9899/COR2:1996 修订。
规则1.2（强制）：不能有对未定义行为或未指定行为的依赖性。
这项规则要求任何对未定义行为或未指定行为的依赖，除非在其他规则中做了特殊说明，都应该避免。
如果其他某项规则中声明了某个特殊行为，那么就只有这项特定规则在其需要时给出背离性。
规则1.3（强制）：多个编译器和/或语言只能在为语言/编译器/汇编器所适合的目标代码定义了通用接口标准时使用。
如果一个模块是以非C 语言实现的或是以不同的C 编译器编译的，那么必须要保证该模块能够正确地同其他模块集成。
C 语言行为的某些特征依赖于编译器，于是这些行为必须能够为使用的编译器所理解。
例如：栈的使用、参数的传递和数据值的存储方式（长度、排列、别名、覆盖，等等）。
规则1.4（强制）：编译器/链接器要确保31 个有效字符和大小写敏感能被外部标识符支持。
ISO 标准要求外部标识符的头6 个字符是截然不同的。
然而由于大多数编译器/链接器允许至少31 个有效字符（如同内部标识符），因此对这样严格而并不具有帮助性的限制的适应性被认为是不必要的。
必须检查编译器/链接器具有这种特性，如果编译器/链接器不能满足这种限制，就使用编译器本身的约束。
规则1.5（建议）：浮点应用应该适应于已定义的浮点标准浮点运算会带来许多问题，一些问题（而不是全部）可以通过适应已定义的标准来克服。
MISRA C++ 2008 规则中文版
迭代语句
迭代语句
迭代语句 迭代语句
跳转语句
跳转语句 跳转语句 跳转语句 跳转语句 说明符
说明符
枚举声明 命名空间 命名空间 命名空间 命名空间 命名空间
命名空间
ASM 声明 ASM 声明 ASM 声明 链接规范
链接规范
链接规范 链接规范
常规
声明符的意思
函数定义
规则 8-4-2 规则 8-4-3 规则 8-4-4 规则 8-5-1 规则 8-5-2
规则 3-1-1
规则 3-1-2 规则 3-1-3 规则 3-2-1 规则 3-2-2 规则 3-2-3 规则 3-2-4
规则 3-3-1
规则 3-3-2
规则 3-4-1
摘要 不必要的构造 不必要的构造 不必要的构造 不必要的构造 不必要的构造 不必要的构造 不必要的构造 不必要的构造 不必要的构造 不必要的构造 不必要的构造
一般表达式
一般表达式 一般表达式 一般表达式 一般表达式 一般表达式
一般表达式
一般表达式 一般表达式 一般表达式 一般表达式 一般表达式 后缀表达式 后缀表达式 后缀表达式
后缀表达式
后缀表达式 后缀表达式 后缀表达式 后缀表达式 后缀表达式 后缀表达式 后缀表达式 后缀表达式 一元表达式 一元表达式 一元表达式 一元表达式 移位运算符
规则 5-0-10
规则 5-0-11 规则 5-0-12 规则 5-0-13 规则 5-0-14 规则 5-0-15
规则 5-0-16
规则 5-0-17 规则 5-0-18 规则 5-0-19 规则 5-0-20 规则 5-0-21 规则 5-2-1 规则 5-2-2 规则 5-2-3
规则 5-2-4
vc2008教程
vc2008教程VC2008是Visual C++ 2008的简称，是微软公司于2008年发布的一款集成开发环境。
本教程将介绍VC2008的基本使用方法，包括安装环境、创建项目、编写代码和调试等方面，帮助初学者快速上手开发。
首先，安装VC2008需要下载安装文件并运行。
安装过程中，可以选择默认设置或自定义设置，根据自己的需求进行选择。
安装完成后，就可以打开VC2008开始使用。
打开VC2008后，接下来需要创建一个项目。
选择“文件”菜单下的“新建”-“项目”，在弹出的对话框中选择“Visual C++”-“Win32控制台应用程序”。
在下一步中，可以输入项目名称和存储路径，然后点击“完成”按钮即可创建项目。
创建项目后，VC2008会自动生成一些初始代码。
这个代码包括了必要的头文件和函数，我们可以在这个基础上进行开发。
例如，在main函数中可以编写自己的代码逻辑，实现自己的功能。
编写代码时，可以使用VC2008提供的代码编辑器。
编辑器支持代码高亮显示、自动补全等功能，能够帮助开发者更高效地编写代码。
在编写代码的过程中，可以使用一些常用的C++语法和函数来实现所需功能。
完成代码编写后，就可以进行调试了。
VC2008提供了一系列的调试工具，如断点调试、变量监视器、内存查看器等，方便开发者对代码进行调试和测试。
在调试过程中，可以逐行执行代码，查看变量的值，定位错误等。
除了基本的项目创建、代码编写和调试，VC2008还提供了其他的功能和工具。
例如，在项目管理方面，可以通过VC2008的解决方案资源管理器对项目进行管理和导航。
在界面设计方面，可以使用VC2008的资源编辑器创建和编辑界面元素。
在发布项目时，可以使用VC2008的部署工具将项目打包为可执行文件或安装程序。
总结一下，VC2008是一款功能强大的开发工具，通过本教程的学习，初学者可以掌握VC2008的基本使用方法。
希望本教程对大家的学习有所帮助，让大家能够更好地利用VC2008进行开发工作。
Microsoft Visual C++ 2008 发布程序的部署问题
Microsoft Visual C++ 2008 发布程序的部署问题VS2008编译的程序在Windows2008环境上运行时经常出现如下问题：应用程序事件日志如下：上述两个问题都解决后则可能还出现如下问题：注意：此时是调用dll出现问题了，而不是运行主程序出错。
主要问题是“找不到从属程序集Microsoft.VC90.MFC”，解决办法如下：将整个“C:\Application\Microsoft Visual Studio 9.0\VC\ redist\x86\Microsoft.VC90.MFC”拷贝到exe文件所在目录下，如果exe程序所涉及调用的dll与该exe文件不在同一目录，那么须要在dll所在目录也拷贝一份。
详细描述如下：这个问题有好多Blog和Forum已经讨论过了，但都不详尽，在具体的操作过程中还是有许多疑问。
我摘录并整合了许多网络文章，希望能够做个最终了结。
一、VC2005和VC2008编译出来的程序如何发布/lf426/archive/2008/04/12/46885.aspxVC2005和VC2008编译出来的程序放到别人的电脑上为什么有可能无法运行呢？1：Microsoft Visual C++ 2008 Express Edition可以发布软件吗？能！很多人说，因为是Express版，不是Studio，所以只是用来练习语言的，不能发布软件——错！除了没有MFC和ATL，基本上跟 .net 版本是一样的。
发布出来的，是完整的可执行文件。
2：VC 2008 (2005) 发布出来的程序必须附带上他们特定的dll文件吗？不一定。
如果目标系统是个经常升级的系统，微软已经为其打上了所需要的dll文件补丁了，不需要在软件包里面附加特定的dll文件。
特别在Vista系统中，你更是不需要VC8和VC9的dll文件。
但是在一些老版本的系统中，这些文件就是必须的。
3：VC2008和VC2005特定的dll文件是哪些？VC8: msvcm80.dll, msvcp80.dll, msvcr80.dllVC9: msvcm90.dll, msvcp90.dll, msvcr90.dll4：如何部署文件？首先，请选择release版本；在生成可执行文件（exe文件）的时候，会得到相应的部署文件（manifest文件）。
pclint misra c 标准的要求 -回复
pclint misra c 标准的要求-回复PCLint是一款静态代码分析工具，常用于C语言和C++代码的检查。
而MISRA C是一套C语言编程规范，它旨在提高软件质量、可靠性与可维护性。
本文将探讨PCLint在MISRA C标准中的要求，并详细介绍如何使用PCLint进行MISRA C规范的静态代码检查。
1. MISRA C标准简介MISRA C是由Motor Industry Software Reliability Association （MISRA）制定的一套面向嵌入式系统的C语言编程规范。
它旨在改善编码质量、提高软件的可靠性和可维护性，规范了C语言的语法和编码风格。
2. PCLint介绍PCLint是由Gimpel Software开发的C/C++静态代码分析工具。
它能够检查代码中的潜在问题和编程错误，并生成详细的报告，指导开发人员进行代码质量的改进。
3. PCLint与MISRA C规范的结合PCLint提供了针对MISRA C规范的专门配置文件，并能够对代码进行准确的静态分析。
通过使用PCLint的MISRA C配置文件，可以更容易地检查代码是否符合MISRA C标准中的要求。
4. PCLint对MISRA C规范的主要要求- 命名规则：变量、函数和宏的命名必须符合特定规范，如使用小写字母和下划线。
- 语法要求：代码必须符合MISRA C提出的语法规则，如禁止使用某些语言特性和语法结构。
- 数据类型：确保使用符合要求的数据类型，并禁止使用不安全的类型转换。
- 注释和文档：代码必须进行适当的注释，以提高代码的可读性和可维护性。
- 错误处理：对于可能发生错误的操作，必须进行适当的错误处理，如检查返回值和处理异常。
- 代码复杂性：代码的复杂性必须控制在合理的范围内，以确保代码的清晰性和可理解性。
- 嵌入式编程相关：对于嵌入式系统开发，还有一些特定的规范要求，如中断处理、内存管理等。
5. 使用PCLint进行MISRA C规范检查的步骤- 配置PCLint环境：下载和安装PCLint，并获取最新的MISRA C配置文件。
MISRA工业标准的C编程规范（一）
MISRA 工业标准的C编程规范(一) MISRA (The Motor Industry Software Reliability Association 汽车工业软件可靠性联会) 是位于英国的一个跨国汽车工业协会，其成员包括了大部分欧美汽车生产商。
其核心使命是为汽车工业提供服务和协助，帮助厂方开发安全的、高可靠性的嵌入式软件。
这个组织最出名的成果是所谓的MISRA C Coding Standard，这一标准中包括了127条C语言编码标准，通常认为，如果能够完全遵守这些标准，则你的C代码是易读、可靠、可移植和易于维护的。
最近很多嵌入式开发者都以MISRA C来衡量自己的编码风格，比如著名的uC/OS-II就得意地宣称自己99％遵守MISRA标准。
而《嵌入式开发杂志》也专门载文号召大家学习。
编码规范通常是一个公司自定的”土政策”，居然有人去做标准，而且还得到广泛的认可，这不禁引起我强烈的兴趣。
可惜这份标准的文本需要花钱去买，而且短短几十页，要价非常昂贵。
MISRA在网上公布了一些文档，其中有关于MISRA C Coding Standard的Clarification报告，从中间你可以大致猜到MISRA标准本身是什么。
我仔细阅读了这些文档，并且通过阅读其他一些介绍性文档，大致了解了MISRA标准的主要内容。
这些条款确有过人之处，对于C/C 语言工程项目的代码质量管理能够起到良好的指导性作用，对于大部分软件开发企业来说，在MISRA的基础上适当修改就可以形成自己的规范。
当然其中也有一些过于严苛的东西，这就需要各个开发部门灵活处理了。
我个人的体会，编码规范虽然很简单，但是要完全执行，不折不扣，需要开发部门有很高的组织性和纪律性，并且有很好的代码评审机制。
因此，如果能够严格地遵守编码规范，本身就是一个开发部门实力的证明。
这里不可能将所有规则一一列出（事实上正式文本我一条也没看到），只列出一些比较有意思的条款，让大家有机会了解MISRA 的风格。
MISRA-C部分规则
Rule 60. 任何if..else if 语句，最后必须有一个收尾的else。例如：
if (ans == 'Y') {
...
}
else if (ans == 'N') {
...
}
else if (ans == 'C') {
...
}
else {
;
}
Rule 67. 循环计数器的值不得在循环体内修改。
Rule 12. 不同名空间中的变量名不得相同。
例如：
typedef struct MyStruct {... } MyStruct; (违规）
struct Person {
char* name;
...
};
char name[32]; （违规）
Rule 13. 不得使用char, int, float, double, long等基本类型，应该用自己定义的类型显示表示类型的大小，如CHAR8, UCHAR8, INT16, INT32, FLOAT32, LONG64, ULONG64等。
Rule 101. 禁止指针运的指针。
Rule 104. 禁止使用指向函数的非常量指针。
Rule 106. 不得将栈对象的地址传给外部作用域的对象。
********************************************************************
后面的规则针对实时嵌入式系统，对其他类型的开发未必适用，如：
Rule 118. 禁止使用动态堆分配（也就是不得使用malloc, calloc和realloc）。
MISRA rules
Specific points Specific pointsRule 5: This is a broadly written rule that limits the use of characters that appear anywhere to be those that are required to be in the source character set. This excludes the characters $ and @, among others. The undefined behavior applies "... except in a character constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token ...".The implementation defined behavior kicks in when the characters are converted to an internal representation. This will occur if the characters appear in a character constant, or a string literal.The rule should be written to exclude the use of these characters within character constants and string literals.Rule 6: This rule excludes the use of an EBCDIC character set. No use of IBM 370's in embedded systems.Given that Rule 5 precludes the use of characters outside of the 91 defined by the standard. It seems pointless to specify that a restricted subset of a standard defining nearly 64000 characters should be used.The rule should be rewritten to specify the ASCII character set (which is already states in a round about way). Or ISO 8859-1 (Latin 1). Rule 7: Trigraphs have a well defined definition. The example given in the commentary refers to an unintentional usage which could result, if the third character were a defined trigraph, unexpected behaviour. MISRA cannot rule against unintentional usage.Software developers working in countries whose keyboards do not offer all of the characters required to write C programs will require special equipment, or to break this rule.Recommending that a compiler operate in a non-standard mode is very bad practice.Rule 9: This precludes the use of a construct that is not supported by the C standard. As such it is a pointless rule.Rul Rule 13:e 13: C permits the basic type to be omitted, i.e., unsigned is equivalent to unsigned int . This rule needs to state that all object andfunction declarations shall include a basic type, via a typedefed identifier.Rule 15: This is not an enforcable coding standards rule.What is a 'defined standard'? Defined by whom?Better wording, should this rule be kept, would be to require a fully documented, publically available, floating point specification.Rule 18: The commentary on this rule fails to capture the true advantage of using suffixes. The type of an integer literal depends on its value and the range of values supported by a given type on a particular implementation. So, for instance, the literal 33000has type long int on a platform where int is 16 bits, but type int, if int is 32 bits. Thus it is possible for the same expression, containing integer literals, to have a different type on different compilers.Rule 22:Incorrect use of terminology here (the wording could also be read to imply that no identifiers should be declared within nested blocks). Only labels have function scope. Identifiers denoting objects have file, block or function prototype scope.This rule could state: 'Declarations of identifiers denoting objects should have block scope unless a wider scope is necessary', or'Declarations of identifiers denoting objects should have the narrowest block scope unless a wider scope is necessary'.Rule 23: This is only half the story. File scope identifiers should be explicitly declared static, or extern. Without an explicit storage class an object is a tentative definition and could be given an implicit initializer at the end of the translation unit. It is tentative in the sense that another, later, file scope, declaration of the same name can result in the storage class being external or static.Also the file scope declaration:const int ci;implicitly has the extern storage class in C and implicitly the static storage class in C++.Rule 24: The example is incorrect. As written the second declaration of x has static storage duration because "... contains the storage-class specifier extern, the identifier has the same linkage as any visible declaration of the identifier with file scope."The following example exhibits the intended behavior:static UI_8 x;void f(void){extern UI_8 x; /* matches against file scope and therefore has static storage class */{extern UI_8 x; /* matches against the block scope declaration* which is hiding the file scope declaration.* So it does not have the same linkage as the* prior declaration.* Has external linkage.*/Rule 26: Nothing crude at all. 6.1.2.6 says "Two types have compatible type if their types are the same.". It then goes on to reference additional conditions under which two types that are not the same can be compatible.Rule 27: The wording here does not clearly state what is intended. An external object is declared whenever a file containing the declaration is included.This rule should state: 'External object declarations should only appear within a single source file, which may be included by other source files one or more times.'Rule 28:The register storage class specifier is at most harmless. It does not change the behavior of a conforming program. It does have other uses in that it can be used to explicitly prevent the address of an object being taken.Rule 29:What does this rule mean? The commentary is no further help. Tags are not initialized, objects declared using tags can be initialized. If the types of the initializers do not match the member types a diagnostic will be issued. Is this a rule about tags, or about initializers?Rule 31:The undefined behaviour referenced in this rule appears in Annex G, but it does not appear in the Normative body of the standard. Bug in the C standard.The rule is effective in making code easier to read and understand The reference to undefined behaviour should be removed.The commentary appearing in the Note, paragraph 4, is poor practice. MISRA should not encourage coding practices that rely on implicit behaviour. The noted behaviour only applies to block scope object definitions. File scope objects, that do not have an explicit initializer, are given a value of zero on program startup.Rule 32: This rule has nothing to do with the implementation defined behavior given in the standard. The standard says "Each enumerated type shall be compatible with an integer type; the choice of type is implementation-defined."In a rather round about way this rule seems to be saying that the values in the definition of an enumeration constant list must not implicitly overlap. If this is the case then the rule needs to say so explicitly.I think it would be good programming practice to ban all implicit and explicit overlaps in each enumeration definition. If there were a need to allow explicit overlapping of values, then it should be required that the value be assigned using the name of the earlier enumeration constant.Another rule is needed to handle the above mentioned implementation defined behavior.Rule 34: This rule should be rewritten so that the user does not have to look up what a primary-expression is.'The operands of the && and || operators shall be enclosed in parenthesis unless they are single identifiers'.MISRA might like to make an exception for some postfix-expressions such as array indexing, structure member selection and function invocations.The Standard does not specify the name of the syntactic rule to which the preprocessor operator defined belongs. Given the naming of other unary operators, the MISRA committee might reasonably say that use of this operator prevents an expression from being a primary-expression i.e, it must be bracketed like the other unary operators.Rule 36:This is not a meaningful rule. It is equivalent to having a rule that states; programs shall not contain bugs.Rule 40: In C90 the behaviour is predictable. The side-effect will not happen. The code is simply misleading. In C9X the side-effect may happen, making the behaviour unpredictable.This rule does help prevent coding bugs through misunderstanding of the Standard.Rule 41: Practical advice would be to require a simple test at program startup to check that the intended behavior is being exhibited by the implementation. Failure of this test generating a diagnostic.Rule 42: If this rule is deemed necessary why is the control expression of a for loop any different than any other situation?There are cases where a comma operator is very useful. The guidelines specify that the rules apply equally to human and machine generated code. For instance in automatically generated code and macro definitions.Rule 43: Implicit conversions loose no more information than explicit ones.Conversions to types capable of representing a wider range of values does not usually loose information (care must be exercised with integer to floating point conversions; rounding may occur for values containing many significant digits).Some coding standards require all casts to be explicit. While others only require explicit casts in those situations where information may be lost.This rule should either state: 'All conversions to narrower types shall be explicit.', or 'All conversions shall be explicit.'Rule 44: The use of typedefs can result in explicit casts that are not strictly necessary. For instance when converting between two types that have been defined using the same underlying base type.It is hard to see how redundant, explicit, casts could cause any more confusion over the rules of promotion than non-redundant, explicit casts. Such a statement by MISRA is itself confusing.Rule 47: This would be better stated in terms of requiring explicit parenthesising of expressions that contain more than one operand. Its category should be increased to required.In C = is an operator. Complete adherence to this rule requires that any expression containing more than one operator be parenthesized.a=(b+c);What about expressions that rely on the implicitly, in the grammar, left to right order of evaluation of expressions? In a+b+c the implicit ordering is a+b followed by adding c to the result. If the three objects have different types it is possible that the result will depend on the order of evaluation.MISRA also needs to add a rule that states: 'No dependence shall be placed on C's left to right evaluation in expressions. The ordering should be made explicit via the use of parenthesis.'Rule 48: The coding in the example is sloppy. Parenthesis should be used to make explicit that the cast, a unary operator, binds to the identifier on its right, not the complete expression.Rule 49: Remove the exception case for boolean operands. It is very unlikely that the implementation will generate different code if an explicit test against zero appears in the source.Rule 51: The behavior for unsigned arithmetic is well defined by the standard. If anything, this rule should apply to signed arithmetic overflow, which is undefined, and not covered by a MISRA rule.Rule 53: As written this rule is too narrow. It is possible for parts of an expression to have no side-effect, i.e., the left hand side of a comma opertaor (in a for statement or otherwise, or one of the arms of the conditional operator. The rule needs to be widened to cover size-effects in expressions.Rule 55:The undefined given on this rule is misleading. The use of labels in itself does not cause undefined behavior. But having more than one label, in the same function, with the same spelling does cause undefined behavior.Rule 57: This is very narrow minded. continue is a structured flow of control statement.Rule 58:This is very narrow minded. break is a structured flow of control statement.Rule 61--64: The reference to Koenig is misleading.Rule 61Rule 66: Poor wording.Presumably what is intended is: 'Only identifiers appearing in the control expression shall appear within the initialization and increment expressions.'Rule 67:Even poorer wording. Numeric variable, iteration counting? Where are these terms defined? Not in the C standard.Presumably what is intended is: 'Identifiers modified within the increment expression of a loop header shall not be modified inside the block controlled by that loop header.'The use of the flag object in the example is an example of how use of a break statement can improve code readability.Rule 73: This rule is a constraint within the C standard and must be diagnosed by a conforming implementation. The MISRA guidelines are not intended to list constraints.Rule 77: This rule is a poorly reworded form of a constraint within the C standard and must be diagnosed by a conforming implementation. The MISRA guidelines are not intended to list constraints.Rule 78: This rule is a constraint within the C standard and must be diagnosed by a conforming implementation. The MISRA guidelines are not intended to list constraints.The undefined behavior highlighted in this rule applies to calls to function that do not have a declaration prototype in scope. Such a situation is prohibited by Rule 71.Rule 79: This is a nonsense rule. Functions having a void return type do not return any value. Attempting to use such a value is a constraint within the C standard and must be diagnoses by a conforming implementation. The MISRA guidelines are not intended to list constraints.The undefined behavior highlighted refers to expressions of type void in general. An attempt to use the non-existent value of a void expression will in general be caught by the type compatibility rules and be a constraint violation.Rule 80: This rule is a constraint within the C standard and must be diagnosed by a conforming implementation. The MISRA guidelines are not intended to list constraints.The undefined behavior highlighted refers to words that appear in Annex G, but that do not appear in the normative body of the standard. Bug in the C standard.Rule 81: This is very poorly worded. All parameters in C are passed by value. It is possible to pass a pointer to an object (but the pointer itself is still passed by value).This rule should state a general condition that any object that is not intended to have its value modified should be defined using the const qualifier.Rule 84: This rule is a constraint within the C standard and must be diagnosed by a conforming implementation. The MISRA guidelines are not intended to list constraints.Rule 85:This is a nonsense rule. An identifier declared to have function, or pointer to function type is only called if it is followed by parenthesis. Otherwise the value of the expression is the address referred to by the object; there is no function call involved.The reference to Koenig is an example of how missing off parenthesis can lead to completely unexpected behavior, i.e. no function call.Rule 87: The reference should be to clause 7.1.2.Rule 94: This rule is a constraint within the C standard and must be diagnosed by a conforming implementation. The MISRA guidelines are not intended to list constraints.The referenced undefined behavior refers to the case of an argument that expands to an empty sequence of preprocessor tokens.This rule should state: 'An argument to a function-like macro shall not consist of no preprocessing tokens.'Rule 98:As stated the rule is wider than the unspecified behaviour given in the C standard. It is not possible to cause unspecified behaviour through the use of more than one # in a macro body. However, use of more than one ##, or use of both # and ## can lead to unspecified behaviour.Rule 101: As written this rule is saying that arrays may not be indexed. Since a[i]is explicitly stated to be equivalent to *(a+1)in the Standard. More thought needs to be put into writing a rule that achieves the desired effect, without outlawing the writing of any meaningful C code.Rule 103: This is poorly worded. The wording reads as if it is permitted to compare pointers to different objects of the same array, structure, or union type.This rule should state: 'Relational operators shall not be applied to objects of pointer type except where both operands are of the same type and both point into the same object.'Rule 104: Confusion. The referenced unspecified behavior has nothing to do with this rule. The two undefined behaviors have nothing to do with this rule and should both refer to 6.3.4 if they are intended to have anything to do with pointers to functions.The first sentence of paragraph one is a good rule. Such casting would make it difficult to check that the correct arguments were being passed to functions. The headline rule refers to non-constant pointers; there is not a lot of connection between the two constructs.Function pointers do not cause problems with dependence on the order of evaluation. The order is unspecified. Previous rules specify that code shall not depend on a particular order of evaluation of an expression.Perhaps what is intended is: 'Pointers to functions shall never be cast, or take part in pointer arithmetic.'Rule 105:Very poorly worded. The reference to undefined behavior should refer to 6.3.4 only.This rule should state: 'Objects of type pointer to function shall never be assigned a value that is incompatible with the object type.'Rule 108: As written the rule makes no sense. The commentary associated with this rule is a constraint within the C standard and must be diagnosed by a conforming implementation. The MISRA guidelines are not intended to list constraints.The reference to undefined behavior should refer to 6.5Rule 109: The reference to undefined behavior should refer to 6.3.16.1 (the cited reference to Clause 7 is not relevant). The reference to implementation defined behavior should refer to 6.3.2.3.This rule means that the union type cannot be used. Within embedded system, where storage space is at a premium, unions are a type safe way for two objects to share storage, provided it is done in a mutually exclusivefashion. MISRA should consider deleting this rule and relying on Rule 110 to achieve the desired result.Rule 110: Rule 109 requires that unions not be used; making this rule redundant.The reference to undefined behavior should refer to 6.3.16.1 (the cited reference to Clause 7 is not relevant).Rule 112:A bit-field object of type signed int and width 1 can represent the values -1and 0. Why forbid this yet allow a bit-field of type unsigned int and width 1, which can represent the values 0 and 1?Of course there is some danger that developers will make the mistaken assumption that the signed case will be capable of holding the values 0 and 1. In which case the rule category should be reduce to advisory.Rule 113:Bit-fields are not the most poorly defined part of the language. Although they may be the most implementation defined part of the language.The purpose of unnamed bit-fields is to adjust the padding of named fields. Packing of members is accepted by MISRA. The wording as it stands seems to imply that developers can somehow access these unnamed members. As such half of this rule is misguided.Declaring a structure or union to contain only unnamed members is undefined behaviour.Rule 119: A very bad rule. errno is not poorly defined. The additional set of values it may take is implementation defined. But this information, error information which MISRA recommends every effort be made to use, cannot be obtained through any other means.The reference to implementation defined behavior is incorrect. "If a macro definition is suppressed in order to access an actual object, or a program defines an identifier with the name errno, the behavior is undefined." The Standard is simply trying to make sure that code does not take advantage of a particular implementation of this identifier.Rule 120:The offsetof macro is a portable method of obtaining the offset of a struct member. The only undefined behavior applies to bit-fields. This rule should state: 'The use of offsetof is recommended.'。
misra-c 解读
misra-c 解读
MISRA-C是一套用于C语言编程的软件开发准则，旨在帮助开发人员创建安全、可靠和高质量的嵌入式系统和应用程序。
它由Motor Industry Software Reliability Association（MISRA）制定，适用于嵌入式系统、汽车电子和其他对软件质量和可靠性要求较高的领域。
MISRA-C的解读包括对C语言编程的多个方面的规定和指导，例如语法、标识符命名、类型使用、内存管理、错误处理、代码结构等。
这些规定和指导旨在提高代码的可读性、可维护性和可移植性，以及减少代码中的潜在错误和缺陷。
具体来说，MISRA-C的一些常见解读包括：
1.避免使用不明确的表达式和行为，以提高代码的清晰度和可维护性。
2.不使用某些不稳定或不建议的C语言特性，以减少潜在的缺陷和错误。
3.在错误处理时避免使用未初始化的变量，以避免不确定的行为和错误。
4.避免悬挂指针（Dangling Pointer）和空指针（Null Pointer）的使用，以
防止内存访问错误。
5.控制代码的复杂性和嵌套层次，以提高代码的可读性和可维护性。
遵循MISRA-C准则，可以帮助开发人员减少软件缺陷、提高代码的可靠性，并符合对高质量、安全性和可维护性的严格要求。
这对于在嵌入式系统、汽车电子或其他类似领域从事软件开发的人员来说非常重要。
总的来说，MISRA-C的解读涵盖了C语言编程的多个方面，旨在提高代码的质量和可靠性。
遵循这些准则可以帮助开发人员创建出更好的嵌入式系统和应用程序。
CNAS实验室工具要求及功能
CNAS实验室建设目录1. 工具要求 (3)1.1. 源代码分析 (3)1.2. 单元/集成测试 (4)1.3. 配置项/系统测试 (5)1.4. 质量体系与管理系统建设 (5)2. 工具配置 (6)2.1. 源代码分析工具 (6)2.2. 单元与集成测试工具 (8)2.3. 配置项/系统测试工具 (10)2.4. 软件测试实验室管理系统 (25)1.工具要求根据CANS实验室目前的能力和规划建设，需要在以下几个方面进行重点考虑：1.1.源代码分析软件测评一般是从源代码开始，尤其是进行单元测试时，代码走查和代码评审是测评中非常重要的一个环节，无论被测软件是通用软件还是嵌入式软件，源代码分析都是测评中的重要工作，在这个阶段主要有如下几个工作要完成：▪软件结构分析（调用关系、控制流、软件复杂性）▪软件编程标准遵循情况▪代码中存在的缺陷和漏洞分析软件结构分析主要是帮助测试人员，对被测软件进行初步了解和熟悉，一般来说，需要得到软件的模块调用关系图和模块的控制流程图，根据这些信息，可以对评测工作进行工作量的预估和评测的任务分配。
并且可以做到科学的、量化的进行决策。
目前软件编程（C语言）需要遵守MISRA C/C++标准，另外有些系统软件需要遵守其所在行业的行业标准甚至单元标准，在评测阶段，有必要对被测软件对标准的遵循情况进行检查，另外一个目的，通过这种标准规范性的检查，可以发现软件可维护性、可移植性和语言的不安全使用的问题，是可以避免一些软件的潜在危险的。
通过源代码分析发现软件中存在的Bug或者安全性漏洞，这种技术目前已经比较成熟，属于新一代的源代码分析技术，而且这种方法能够以比较经济，快速，简便的方式获取重要的分析结果，例如，可以发现空指针引用的问题、数组越界的问题、内存泄漏的问题。
这类问题对于嵌入式系统来说都是非常致命的，如果通过动态测试发现这类问题，难度很大，需要设计特定的测试用例，即使这样，有些问题也是不能通过测试用例复现的，静态分析技术的好处是可以通过理论推导，虚拟的运行里面的所有路径，发现每一条路径中可能存在的问题。
学习MISRAC之五：准确的程序流控制——（转）
学习MISRAC之五：准确的程序流控制——（转）学习MISRAC之五:准确的程序流控制——（转）程序的执行流程是由条件判断、跳转和循环构成的,没有任何一个程序会缺少程序流的控制。
那么像if 、for 、while 、switch 等这些程序员无比熟悉的语句也存在隐患吗? 事实上,C 语言是很灵活的,这种灵活性给程序员编写代码带来了很多便利,但同时也带来了很多容易导致混淆的表达。
这些表达完全符合C 语言标准,但有时程序员也难以发现自己犯了错误,最终的结果是使程序进入错误的执行流程。
即使程序员没有犯错误,但有些容易混淆的表达也会给其他人读懂程序带来困扰,使程序的维护变得困难。
除此以外,有少量控制流程的方式还会产生不确定的运行结果,而这些结果也不容易被发觉。
如何使程序的流程控制清晰、准确,不产生混淆的表达呢? MISRA C 给出了很多的相关规定,使程序流的控制变得规范,避免产生各种混淆和不确定性,从而最大程度上减少程序流控制中的失误, 并使程序的维护更加容易。
下面从几个例子出发,讲述这些混淆是如何产生的,最后给出MISRA C 关于程序流控制的相关规则,帮助读者规范编程的习惯。
1 容易混淆的表达方式先来看这样两段代码:uint8_t x ,y ;if ( x = = y) {foo ( ) ;}uint8_t x ,y ;if (x = y) {}在C 标准中,条件语句需要的是布尔值,条件语句表达式的布尔值实际上是按照整型处理的,所以这两段代码在语法和逻辑上都没有任何问题。
第一段代码判断x 是否等于y ,如果相等,调用foo () 函数;第二段代码首先将y的值赋给x ,然后判断x 是否为0 ,如果不为0 ,调用foo ()函数。
这两段代码只相差一个等号,却使判断条件大不相同,程序的执行流程会出现很大差别。
相信读者在写程序的时候都碰到过将“= = ”这个判断语句误写成赋值语句“= ”的情况。
那么面对这两个语句时,如何能快速准确地判断这是正确的还是程序员的失误呢? 当程序比较简单的时候,很容易判断,但当程序流程比较复杂的时候,可能花费大量时间还难以给出确定的答案,而这些地方极有可能是有错误的。
MISRA C++:2008讲座(4)异常机制的使用
MISRA C++：2008讲座(4)异常机制的使用
黄土琛;邵贝贝
【期刊名称】《单片机与嵌入式系统应用》
【年(卷),期】2009(000)012
【摘要】异常机制是C++崭新而高级的特性,比起传统的返回错误代码的做法,异常机制能够针对各种可能的错误提供更有效的解决方法,而且可以使正常代码和错误处理清晰划分开来.关于如何安全、可靠地使用异常机制,MISCRA C++给出了一些相关的规范.
【总页数】4页(P78-81)
【作者】黄土琛;邵贝贝
【作者单位】清华大学;清华大学
【正文语种】中文
【相关文献】
1.MISCRA C++:2008讲座(1) C++在嵌入式应用中的安全问题 [J], 林轶;邵贝贝
2.MISRA C++2008讲座(2)完备地实现C++多态性 [J], 王玺;邵贝贝
3.MISRA C++:2008讲座(3)类的封装与继承 [J], 林轶;邵贝贝
4.利用异常机制的C++类型恢复方法 [J], 蒋凡;徐晓睿
5.MISRA C++新规范改善高安全性要求控制系统 [J],
因版权原因，仅展示原文概要，查看原文内容请购买。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Rule YesorNo[2]Rule YesorNo[2]Rule YesorNo[2]Rule YesorNo[2]0-1-1 Y 4-5-3 N 6-4-5 Y 10-3-2 N0-1-2 Y 4-10-1 N 6-4-6 Y 10-3-3 N0-1-3 X[3] 4-10-2N 6-4-7Y 11-0-1Y 0-1-4 Y 5-0-1 Y 6-4-8 N 12-1-1 Y0-1-5 N 5-0-2 Y 6-5-1 Y 12-1-2 N0-1-6 N 5-0-3 N 6-5-2 Y 12-1-3 Y0-1-7 Y 5-0-4 X[13] 6-5-3Y 12-8-1Y 0-1-8 N 5-0-5 X[14] 6-5-4N 12-8-2N 0-1-9 X[4] 5-0-6Y 6-5-5X[17] 14-5-1N 0-1-10 X[5] 5-0-7N 6-5-6N 14-5-2Y 0-1-11 X[6] 5-0-8N 6-6-1Y 14-5-3Y 0-1-12 X[6] 5-0-9N 6-6-2Y 14-6-1N 0-2-1 Y 5-0-10 Y 6-6-3 Y 14-6-2 N0-3-1[1] N 5-0-11 N 6-6-4 Y 14-7-1 N0-3-2 Y 5-0-12 N 6-6-5 Y 14-7-2 N0-4-1[1] N 5-0-13 Y 7-1-1 N 14-7-3 N0-4-2[1] N 5-0-14 Y 7-1-2 Y 14-8-1 N0-4-3[1] N 5-0-15 Y 7-2-1 Y 14-8-2 N1-0-1 X[7] 5-0-16Y 7-3-1Y 15-0-1[1] N1-0-2[1] N 5-0-17 Y 7-3-2 Y 15-0-2 Y1-0-3[1] N 5-0-18 X[15] 7-3-3Y 15-0-3N 2-2-1[1] N 5-0-19 Y 7-3-4 N 15-1-1 Y2-3-1 Y 5-0-20 X[16] 7-3-5N 15-1-2Y 2-5-1 N 5-0-21 Y 7-3-6 Y 15-1-3 N2-7-1 Y 5-2-1 Y 7-4-1[1] N 15-3-1 X[20]2-7-2 N 5-2-2 Y 7-4-2 N 15-3-2 Y2-7-3 N 5-2-3 Y 7-4-3 X[18] 15-3-3N 2-10-1 N 5-2-4 Y 7-5-1 Y 15-3-4 N2-10-2 Y 5-2-5 Y 7-5-2 Y 15-3-5 Y2-10-3 X[8] 5-2-6Y 7-5-3N 15-3-6Y 2-10-4 X[9] 5-2-7Y 7-5-4Y 15-3-7Y 2-10-5 X[10] 5-2-8 Y 8-0-1Y 15-4-1Y 2-10-6 Y 5-2-9 Y 8-3-1 Y 15-5-1 Y2-13-1 Y 5-2-10 Y 8-4-1 Y 15-5-2 Y2-13-2 Y 5-2-11 Y 8-4-2 Y 15-5-3 Y2-13-3 Y 5-2-12 Y 8-4-3 Y 16-0-1 Y2-13-4 Y 5-3-1 Y 8-4-4 Y 16-0-2 Y2-13-5 N 5-3-2 Y 8-5-1 Y 16-0-3 Y3-1-1 Y 5-3-3 Y 8-5-2 Y 16-0-4 Y3-1-2 N 5-3-4 Y 8-5-3 Y 16-0-5 Y3-1-3 Y 5-8-1 Y 9-3-1 N 16-0-6 Y3-2-1 N 5-14-1 Y 9-3-2 X[19] 16-0-7Y 3-2-2 N 5-17-1 N 9-3-3 Y 16-0-8 Y3-2-3 Y 5-18-1 Y 9-5-1 Y 16-1-1 Y3-2-4 X[11] 5-19-1Y 9-6-1[1] N 16-1-2 Y3-3-1 Y 6-2-1 Y 9-6-2 Y 16-2-1 X[21]3-3-2 Y 6-2-2 Y 9-6-3 Y 16-2-2 Y3-4-1 X[12] 6-2-3 Y 9-6-4Y 16-2-3YRule YesorNo[2]Rule YesorNo[2]Rule YesorNo[2]Rule YesorNo[2]3-9-1 N 6-3-1 Y 10-1-1Y 16-2-4 Y3-9-2 Y 6-4-1 Y 10-1-2N 16-2-5 Y3-9-3 Y 6-4-2 Y 10-1-3N 16-2-6 Y4-5-1 Y 6-4-3 Y 10-2-1N 16-3-1 Y4-5-2 N 6-4-4 Y 10-3-1N 16-3-2 Y16-6-1[1] N 17-0-4[1]N 18-0-3Y 18-4-1Y 17-0-1 Y 17-0-5 Y 18-0-4Y 18-7-1 Y17-0-2 Y 18-0-1 Y 18-0-5Y 19-3-1 Y17-0-3 Y 18-0-2 Y 18-2-1Y 27-0-1 Y[1]: Rules required for documentation.[2] Y: Violation of the MISRA rule can be indicatedN: Violation of the MISRA rule can not be indicatedX: Rules, that during static analysis are difficult to check but that will be checked if possible.[3]: Messages will be indicated for unused variable which is neither global variable nor member variable.[4]: Messages will be indicated for the source code that it maybe executed, while even be deleted, no effect to the function will be produced.[5]: Messages will be indicated for unused static function.[6] Messages will be indicated for unused parameter.[7]: Messages will be indicated for descriptions which is not compliant with C++2003(ISO/ICE 14882:2003).[8]: Messages will be indicated for duplicating typedef name.[9]: Messages will be indicated for duplicating class name, struct name, union name andenum name.[10]: Messages will be indicated for defining identifiers with the same name outside andinside the function.[11]: Messages will be indicated for defining the external variables with the same name of atype in a file.[12]: Messages will be indicated for using global static variable only in one function.[13]: Messages will be indicated for comparing signed value and unsigned value.[14]: Messages will be indicated for assigning the result of integer operation(+,-,*,/)to thefloating type or comparing it with the floating type.[15]: Messages will be indicated if the comparison is made between the addresses of objects with different types.[16]: Messages will be indicated if the operand of bit operation is non-integer type.[17]: Messages will be indicated if an irrelevant variable exists in the loop condition of for statement.[18]: Messages will be indicated if an assemble statement is used.[19]: Messages will be indicated if the address of non-const member which has a morestrict access limit is used as the return value.[20]: Messages will be indicated if a new expression or a delete expression is written out ofthe try block in constructor or destructor.[21]: Messages will be indicated in the following cases:z Macro function was defined.z The integer constant has been defined for Macro.。