C语言编程规范MISRAC2012_misarc标准,misarc标准资源-CSDN文库

2星需积分: 50 21 浏览量 2018-12-31 13:42:10 上传评论 6 收藏 308KB PDF 举报

在当今的软件开发领域，编程规范是确保代码质量和可维护性的重要工具。特别是在汽车电子行业中，由于其高安全性和可靠性要求，编程规范更是必不可少。MISRA C是一套特别针对C语言制定的编程规范，主要用于汽车行业。MISRA C 2012是该规范的一个版本，而MISRA C 2012 Addendum 1则是该规范的一个补充文件，其中包含了规则映射和变动的具体信息。 MISRA是Motor Industry Software Reliability Association的缩写，是汽车行业中推动软件可靠性的一个组织。该组织发布了一系列的C语言编程指南，以减少软件开发中的错误。MISRA C规范主要用于嵌入式系统编程，比如汽车电子控制单元（ECU）中的软件开发。为了提升软件质量，MISRA C提供了一套强制性和建议性的编程规则。 MISRA C 2012规范对C语言的版本做出了要求，它兼容C90标准和C99标准。不过，MISRA C 2012相较于之前的版本，在对C语言标准的具体要求上有所改变。例如，在MISRAC:2004中，对标准C代码的使用是隐含禁止扩展的。但是到了MISRAC:2012，规则1.1允许扩展，但这些扩展受到新规则1.2的限制，规则1.2是一个建议性规则，它放宽了对非关键性的未指定行为的限制。在MISRAC:2012中，对代码的某些规则进行了更新和划分。比如规则1.3、1.4和1.5从强制性规则变成了指导性规则，因为它们不易通过静态检查来验证。规则2.1需要严格记录汇编语言的使用，而规则2.2和规则2.3则分别对C90和C99代码中允许使用注释的条件做出了不同要求。另外，规则3.1和规则3.2也发生了变更，它们从强制性规则变成了指导性规则。规范中的“Dir”前缀表明某些规则已经变成了推荐性指导（即不作为强制性要求），以便提供灵活性并允许在特定情境下根据实际需要使用。MISRAC:2012的附录H列出了MISRAC:2012相较于MISRAC:2004对于C90代码的重要变更。在实际应用中，遵守MISRA C规范可帮助开发者避免编程中的一些常见错误，例如，规范中明确禁止使用某些可能会引起安全问题的C语言特性和构造。由于汽车电子系统的复杂性，使用MISRA C标准的代码可以减少程序出错的机会，降低风险，最终确保车辆的安全性。 MISRA C 2012提供了一套完整的编程指导原则，旨在帮助开发者编写清晰、可靠、可维护的代码。通过遵循这些规则，汽车行业的软件开发者可以提高软件质量和产品的安全性。MISRA C 2012 Addendum 1则帮助开发者理解新规范与旧规范之间的差异，并指导他们如何平滑过渡。由于汽车电子系统中软件的复杂性日益增加，这些规范的重要性不言而喻。

资源推荐

资源详情

资源评论

MISR A C:2012

Addendum 1 — Rule Mappings

March 2013

MISRAC:2012 Addendum: RuleMappings

MISRAC:2004 to MISRAC:2012 rule mapping

MISRAC:2004 MISRAC:2012 Signicant changes from MISRAC:2004 for C90 code

Rule1.1 (required) Rule1.1 (required) The requirement that code conform to a version of

the standard has moved into an introductory section.

MISRAC:2004 Rule1.1 had an implied ban on extensions.

MISRAC:2012 Rule1.1 permits extensions, but they are

restricted by the new advisory Rule1.2.

Rule1.2 (advisory)

Rule1.2 (required) Rule1.3 (required) Relaxed to permit unspecied behaviour that is not

considered critical. MISRA C:2012 AppendixH lists the

issues that are covered.

Rule1.3 (required) Dir1.1 (required) Changed to a directive as it is not a statically checkable rule.

Rule1.4 (required) Dir1.1 (required) Changed to a directive as it is not a statically checkable rule.

Rule1.5 (advisory) Dir1.1 (required) Changed to a directive as it is not a statically checkable rule.

Rule2.1 (required) Dir4.2 (advisory) Tightened to require documentation of assembly usage.

Dir4.3 (required)

Rule2.2 (required) Rule1.2 (advisory) Relaxed to permit // comments in C99 code.

Downgraded to advisory for C90.

Rule2.3 (required) Rule3.1 (required)

Rule2.4 (advisory) Dir4.4 (advisory) Changed to a directive as MISRAC:2012 does not precisely

describe what constitutes code in a comment.

Rule3.1 (required) Dir1.1 (required) Changed to a directive as it is not a statically checkable rule.

Rule3.2 (required) Dir1.1 (required) Changed to a directive as it is not a statically checkable rule.

Rule3.3 (advisory) Dir1.1 (required) Changed to a directive as it is not a statically checkable rule.

It is not an issue for C99 because the standard species the

behaviour.

Rule3.4 (required) Dir1.1 (required) Changed to a directive as it is not a statically checkable rule.

Rule3.5 (required) Dir1.1 (required) Changed to a directive as it is not a statically checkable rule.

Rule3.6 (required) Deleted This issue is now covered by the Introduction to the Rules

section.

Rule4.1 (required) Rule4.1 (required) Relaxed to permit octal and hexadecimal escapes providing

that they are properly terminated. C90Undened 11 (an

undened escape sequence is used) is now covered by

Rule1.3.

Rule4.2 (required) Rule4.2 (advisory) Downgraded to advisory because there is no undened

or unspecied behaviour associated with trigraphs. There

are certain source character sets in which it would be

impossible to write C programs without trigraphs.

Rule5.1 (required) Rule5.1 (required) Relaxed to permit the identiers to be distinct up to the

limit allowed by the implementation.

Rule5.2 (required)

Rule5.3 (required)

Rule5.4 (required)

Rule5.5 (required)

Rule5.2 (required) Rule5.3 (required)

MISRAC:2004 to MISRAC:2012 rule mapping

MISRAC:2004 MISRAC:2012 Signicant changes from MISRAC:2004 for C90 code

Rule5.3 (required) Rule5.6 (required) Relaxed to permit tag names that are the same as typedef

names.

Rule5.4 (required) Rule5.7 (required) Relaxed to permit tag names that are the same as typedef

names.

Rule5.5 (advisory) Rule5.8 (required) Relaxed to permit static identiers declared in a block to

have the same name as other identiers.

Rule5.9 (advisory)

Rule5.6 (advisory) Deleted Relaxed to permit identiers such as labels and

enumeration constants that are not in the same scope to

have the same identier.

Rule5.7 (advisory) Deleted Relaxed to permit identiers such as structure members

names in dierent structures.

Rule6.1 (required) Rule10.1 (required) Relaxed to allow addition of plain char and a dierent

integer type, and subtraction of two plain char.

Rule10.2 (required)

Rule10.3 (required)

Rule10.4 (required)

Rule6.2 (required) Rule10.1 (required)

Rule10.3 (required)

Rule10.4 (required)

Rule6.3 (advisory) Dir4.6 (advisory)

Rule6.4 (required) Rule6.1 (required) Relaxed to permit other legal C99 bit-eld types

Rule6.5 (required) Rule6.2 (required) Relaxed to permit unnamed bit-elds with a signed type to

be single-bit.

Rule7.1 (required) Rule4.1 (required) Relaxed to permit octal escape sequences providing they

are properly terminated.

Rule7.1 (required)

Rule8.1 (required) Rule8.2 (required) Tightened to require all function types to be in prototype

form with named parameters.

Relaxed to permit function denitions with no separate

declaration if they have internal linkage.

Rule8.4 (required)

Rule17.3 (mandatory)

Rule8.2 (required) Rule8.1 (required) Tightened to require all types to be explicitly stated,

e.g. structure members.

Rule8.3 (required) Rule8.3 (required)

Rule8.4 (required) Rule8.3 (required) Tightened to require identical object types

Rule8.5 (required) Deleted This rule has been deleted because some programming

paradigms require the presence of executable code in

a header le. It is also desirable for inline functions to

appear in header les so as to avoid undened issues. The

problems associated with multiple declaration/denition of

objects/functions are dealt with by other rules.

Rule8.6 (required) Deleted Relaxed to permit declarations using the extern keyword

at block scope, but more specic problems are caught by

other rules such as:

• Rule1.3: Undened behaviour due to use of the static

keyword

• Rule8.3: Compatibility of multiply-declared/dened

objects/functions

剩余15页未读，继续阅读

评论收藏

内容反馈

yzhij

2020-04-22

谢谢楼主的分享资料
知识混子

2022-02-23

垃圾内容，骗积分的
脚踏实地-仰望星空

2021-09-25

不要下载，不完整。

璨CAN

粉丝: 4
资源: 18

C语言编程规范 MISRA C 2012

最新资源

C语言编程规范 MISRA C 2012

基于MISRA C2012 C语言编程规范

MISRA C_2012 Guidelines

MISRA_C_2012_规范

MISRA2012 Guideline

C语言编程规范 MISRA C 2012 + MISRA2012 Guideline + 英文MISRA-C-2012

MISRA-C 2012_中文翻译版.pdf

MISRA C 2012 英文版 + 2004 中英文 pdf

MISRA C 2012 协议全集(包括所有修订版)

MISRA-C-2012-Eng.pdf

MISRA C 编程规范

C编程规范 MISRA C规范

C语言编程规范 MISRA C 2012 TC1

MISRA C 2012规范.pdf

MISRA C 2012规范-中文精校版

学习MISRAC之一“安全第一”的C语言编程规范[参照].pdf

C语言编程规范MISRAC中文

汽车行业的C语言编程规范

MISRA C 2012编码规范中文版

MISRA-C-2004-工业标准的C编程规范-中文版.rar_MISRA C

C语言编程规范之misrac[定义].pdf

MISRA C_2012 Guidelines for the use of the C language in critical systems.pdf

MISRA C2012介绍_中文

MISRA C2012 Guidelines for the use of the C language in critical systems.pdf

MISRA C2012——规则.zip

MISRA C 编码规范（中英文）

MISRA_C_Guidelines_2012.pdf

MISRA C 2012 AMD-1.rar_C misra_MISRA_MISRA C_MISRA C 2012_amd

MISRA C/C++合集 2004/2008/2012

最新资源