MISRA-C2012とISO/IEC 9899:2011 at OSCNagoya2013

MISRA-C2012とISO/IEC 9899:2011
MISRA-C-Training ver6 2013.06.20

工学博士・技術士（情報工学）
名古屋市工業研究所小川清

2013/12/14

(c)kaizen@wh.commufa.jp, @kaizen_nagoya

今頃C言語？
•

CPUが実行するのは機械語。

•

多くのCPU提供者が、CPUとアセンブラ、Cコンパイラを同時に

•

実行している内容でよいかどうかをたしかめるのはアセンブラ。

•

min-CAMLでは直接アセンブラを生成することによって高速化を

•

Cを生成すれば、対応CPUが一気に広がる。

•

UNIX/LinuxなどのOSはCで記述している。

•

CコンパイラをCで記述している。

•

アセンブラで書けることなら、Cで書ける。
2013/12/14


よくある意見
Q: プログラミング言語の自動生成をしていて自分でコードを書
かないので関係ない。
A: 自動生成でC言語を使っているとキャストの仕方が不十分で
誤差が拡大したり、０割の発生原因となります。MISRAで
は、自動生成の出力規則も定義しています。
Q: 試験(test)担当で、直接コードを書かないので関係ない。

A: MISRA-Cは、C言語の部分集合(subset)です。MISRA-Cに対
応すると試験がしやすいコードになります。
Q: 自分は天才プログラマなので一切の規制に反対する。

A: 天才の書いたプログラムを、凡人が間違ったプログラムにし
てしまうことがあります。凡人にも理解出来るコードが書
けるのも天才の技の一つとお考えください。
2013/12/14

背景


CPU販売者が言語としてアセンブラとCを提供。


CコンパイラもCで記述



CPUの発展を阻害しないように、Cプログラマに不
必要な負荷をかけないように(Cの精神:the spirit of
c）、C言語規格には「未規定」，「未定義」，「処
理系定義」がある。
 C言語規格には


OSの存在を前提としたホスト環境（OSあり,mainあ
り）と
 OSの存在を必ずしも想定していないフリースタンデ
ィング環境とがある。OSなくてもよくMainは必要な
い。


C言語規格にはOSの一部かもしれないライブラリがある。
2013/12/14


Ｃ言語の規格


K&R（デファクト）C言語の作者の文書
 アメリカ規格（デジュール）
 ANSI X. 1989(C89):1999版からISO/IECの標準制
定と同時進行
 国際規格:フリースタングィング環境(main無可)，
ホスト環境（main引数有）
 ISO/IEC 9899:1990(C90=ANSI C89)
 ISO/IEC 9899:1999(C99)
 ISO/IEC 9899:2011(C2011)
 国内規格
 JIS X 3010:1993(C90), JIS X 3010：2004(C99)
 www.jisc.go.jpで無償で閲覧可
2013/12/14


JIS C解説(Cの精神） © JIS
1.既存のコードを救うことが重要であり、既存の処理系を保護することは、重
要視しない。
2.可搬性のある原始プログラムが書けるようにする。 (高級アセンブラ的な使
い方による）可搬性がないプログラムを禁止してはならない。
3.(既存の仕様からの）暗黙の意味変更（quiet change)は極力避ける
4.規格は処理系の作成者とプログラマとの間の約束事を記述するものである。
5. 次のCの精神を遵守する.
1.
プログラマを信頼する
2.
プログラマが必要である事項を行うことを妨げない
3.
言語は小さく、コンパクトに保つ
4.
一つのオペレーティングシステムには唯一の方法を割り当てる
たとえ可搬性が保障されない方法であったとしても、実行効率を上げる余地を
残しておく。

2013/12/14


The spirit of C, Additional Principles for
C1X
ISO/IEC JTC1 SC22WG14 N1250
12. Trust the programmer, as a goal, is outdated in respect to the
security and safetyprogramming communities. While it
should not be totally disregarded as a facet of the spirit of C, the
C1Xversion of the C Standard should take into account that
programmers need the ability to check their work.
13. Unlike for C9X, the consensus at the London meeting was that there
should be no invention, without exception. Only those features that
have a history and are in common use by a commercial
implementation should be considered. Also there must be care to
standardize these features in a way that would make the Standard
and the commercial implementation compatible.
14. Migration of an existing code base is an issue. The ability to mix and
match C89, C99, and C1X based code is a feature that should be
considered for each proposal.
2013/12/14

動くプログラムで教育（応用
）


C Puzzle Book




トリッキーなプログラ
ムの確かめ

C言語の落とし穴


MISRAに対応規則記述



Cコンパイラ自体のコン
パイル



OSのソースのコンパイ
ル


TOPPERS

2013/12/14


問題１
From C Puzzle book© 1.1
#include <stdio.h>
intmain(intargc, const char * argv[])
{
intx;
x = -3 + 4 * 5 -6; printf("%dn",x); //(1.1.1)11
x = 3 + 4 % 5 - 6; printf("%dn", x);//(1.1.2)1
x = -3 * 4 % -6 / 5; printf("%dn", x);//(1.1.3)0
x = ( 7 + 6 ) % 5 / 2; printf("%dn", x);//(1.1.4)1
return 0;
}

2013/12/14


問題１
From C Puzzle book© 1.1
11
1
0

1

2013/12/14


問題２
From C puzzle book ©2.1
#define PRINT(format,x) printf(#x " = %" #format "n",x)
int integer = 5;
char character = '5';
char * string = "5”;
{ PRINT(d, string); PRINT(d, character); PRINT(d,integer); //(2.1.1)
PRINT(s, string); PRINT(c, character); PRINT(c,integer=53); //(2.1.2)
PRINT(d, ('5' > 5));
//(2.1.3)
{ intx = -2;
unsigned intux = -2;
PRINT(o,x); PRINT(o,ux); //(2.1.4)
PRINT(d,x/2); PRINT(d,ux/2); //(2.1.5)
PRINT(o,x>>1); PRINT(o,ux>>1); //(2.1.6)
PRINT(d,x>>1); PRINT(d,ux>>1); //(2.1.7)
return 0;
}
}
2013/12/14

Defs.h(Cpuzzle book ©)
#ifndef puzzle4_1_defs_h
#define puzzle4_1_defs_h

#include <stdio.h>
#define PR(fmt,val) printf(#val " = %" #fmt "t", (val))
#define NL putchar('n’)
#define PRINT1(f, x1) PR(f,x1), NL
#define PRINT2(f, x1,x2) PR(f,x1), PRINT1(f,x2)
#define PRINT3(f, x1,x2, x3) PR(f,x1), PRINT2(f,x2,x3)
#define PRINT4(f, x1,x2, x3, x4) PR(f,x1),
PRINT3(f,x2,x3,x4)
#endif
2013/12/14


Puzzle book ©4.1
#include "defs.h"
{ intx, y=1, z;
if( y!=0) x=5;
PRINT1(d,x); //(4.1.1)
if(y==0) x=3;
else x=5;
PRINT1(d,x); //(4.1.2)
x=1;
if(y<0) if (y>0) x=3;
else x=5;
PRINT1(d,x); //(4.1.3)
if (z=y<0) x=3;
else if (y==0) x=5;
else x=7;
PRINT2(d,x,z); //(4.1.4)
if(z =(y==0))x=5;
x=3;
PRINT2(d,x,z); //(4.1.5)
if(x=z=y); x=3;
PRINT2(d,x,z); //(4.1.6)
return 0;
2013/12/14

問題３


問題４
From Puzzle book© 6.1
#include "defs.h”
inti=0;
{
auto inti=1;
PRINT1(d,i);//(4.1.1)
{
inti=2;
PRINT1(d,i);//(4.1.2)
{
i+=1;
PRINT1(d,i);//(4.1.3)
}
PRINT1(d,i);//(4.1.4)
}
PRINT1(d,i);//(4.1.5)
return 0;
}
2013/12/14


問題５

From C puzzle book© 7.1
#include "defs.h"
int a[] = {0,1,2,3,4};
{ inti, *p;
for ( i=0; i<=4; i++) PR(d,a[i]);//(5.1.1)
NL;
for(p=&a[0]; p<=&a[4]; p++) PR(d,*p);//(5.1.2)
NL;NL;
for(p=&a[0],i=1; i<=5; i++) PR(d,p[i]);//(5.1.3)
NL;
for(p=a, i=0; p+i<=a+4; p++,i++) PR(d,*(p+1));//(5.1.4)
NL;NL;
for( p=a+4; p>=a; p--) PR(d,*p);//(5.1.5)
NL;
for( p=a+4,i=0; i<=4;i++) PR(d,p[-i]);//(5.1.6)
NL;
for(p=a+4;p>=a;p--) PR(d, a[p-a]);//(5.1.7)
NL;
return 0;
}
2013/12/14


問題６
Ｃプログラミングの落とし穴© 1.1章参考
#include "defs.h”
{

intx = 1, y=0;

if (x = y) PRINT2(d,x,y);//Using result of an
assignment as a condition without parentheses.
else PRINT2(d,y,x);

return 0;}
2013/12/14


問題７
Ｃプログラミングの落とし穴©1.4章参考
#include "defs.h”
{
// insert code here...
struct {
intpart_number;
char * description;
} parttab[]={
046, "left-handed widget",
047, "right-handed widget",
125, "frammis"
};
for (inti=0; i<3; i++){
PRINT1(d, parttab[i].part_number);
NL;PRINT1(s, parttab[i].description);

}
}

return 0;
2013/12/14


#include "defs.h”
{
struct {
intpart_number;
char * description;
} parttab[]={
046, "left-handed widget",
047, "right-handed widget",
125, "frammis"
};

問題８

for (inti=0; i<3; i++){
PRINT1(d, parttab[i].part_number);
NL;PRINT1(s, parttab[i].description);
}
return 0;
}
2013/12/14


問題9
#include "defs.h”
{
printf("%dn",square(1.9));//implicit declaration of function
// 'square' is invalid in C99
printf("%gn",square(1.9));//Format specified type 'double
//but the argument has type 'int’
}
intsquare(doublex)
{ return (int) x*x;}
2013/12/14


問題１０

#include <stdio.h>
#define absm(x) x>=0?x:-x
intmain(intargc, constchar * argv[]){
inta=1, b=2;
printf("%dn",absm(a-b));

return0;
}
2013/12/14


問題の総括
CPU, コンパイラによって振る舞いの違うコード
が書けてしまう。 ->未規定、未定義、処理系
定義
可読性の悪いプログラムは、差分開発で書いた
本人も間違える可能性がある
影響の範囲が特性しやすいプログラム
MISRA-Cに対応すると関数プログラミングに近
づく

2013/12/14


未定義(undefined)と未規定
(unspecified)

3.4.3 undefined behavior: behavior, upon use of a non portable
or erroneous program construct or of erroneous data, for which
this International Standard imposes no requirements
NOTE Possible undefined behavior ranges from ignoring the situation
completely with unpredictable results, to behaving during translation or
program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to
terminating a translation or execution (with the issuance of a diagnostic
message).
EXAMPLE An example of undefined behavior is the behavior on integer
overflow.

3.4.4 unspecified behavior: use of an unspecified value, or
other behavior where this International Standard provides two
or more possibilities and imposes no further requirements on
which is chosen in any Instance
EXAMPLE An example of unspecified behavior is the order in which the
2013/12/14


課題の背景
自称「Cプログラマ」でC言語規格の存在、内容を
知らない人がいる?

WEBに審議文書を公開している開かれた規格。
http://www.open-std.org/itc1/sc22/wg14/
CPU、コンパイラによって振る舞いが違うコードの
存在を知らない人がいる
プログラマが何でもできようにしてあるが、何をし
たらいいかの知見をためるのがMISRA-C

http://researchmap.jp/kaizen/MISRA-C/
2013/12/14


全問正解の方
MISRA-C:2012の解説書を差し上げます。
現在、構想。

MISRA-C 2013研究会
解説書を作ろう

2013/12/14


目的


異なるCPUでコンパイルしたときに同じ振舞をする
安全なシステムを構築するための試験，証明。
 大規模化するソフトウェアの構造化。
 CPUに依存した処理が書ける（高級アセンブラ）。




C言語教育に必要なこと。


Cコンパイラを理解する（改良できる）：C言語で記述
 OSを理解する（改良できる）：C言語で記述
 ネットワークを理解する（改良できる）：C言語で記述


C言語試験、証明
空間（集合）の制限：MISRA-C
 時間の検証：HDLならSTARC RTL設計スタイルガイド


2013/12/14


C2011で嬉しいこと
Aｌlignを規定した
GCCとObjective-Cでallignが違う。
Min-CAMLのコンパイルで失敗中。
Min-CAMLはアセンブラを出力している。

C言語を出力するようにすれば対応CPUが増える。

2013/12/14


MISRA-C 2012で嬉しいこ
と
C90, C99に両対応
//コメント、bool定義が基本。

規則の大分類を入れより体系的に
Directive（指令）
Rule(規則)

検査しやすいように

2013/12/14


ここで確認。
1. C言語規格の審議過程（規格相当文書を含む）が

閲覧できる
2. JIS 規格が無償で閲覧できる。
3. C言語には、Cの精神、技術の発展のため、いろ

いろなことができるようになっている。
4. 自動車などの安全性の必要なプログラムは、で

きるだけ自由をなくして、なるべく唯一の方法
をえらぶように習慣づける

2013/12/14


MISRA-Cの確認
CプログラムがCPU、コンパイラで異なる振る舞い
をすることを防ぎ、CPU,コンパイラで同じ仕事をす
るようにする。
部分集合を定義しているので試験のしやすい、可読
性の高いプログラムになる。
検査は複数の手段、道具を使うことを推奨している。
(合致表）
規則を守ることが大事なのではなく、なぜそうする
とよいかどうかの判断ができる。規則を守ると
言語のFailure Modeをさける規則を列記しているの
でソフトウェアFMEAの作業の最初として役立つ。
2013/12/14


中間まとめ
C言語系のプログラマはC言語の脆弱性をよく理解
するため、無料で手に入るC言語規格を利用しよう
できればＣコンパイラを書いてみると良い。
オープンソースのＣコンパイラをいじるだけでもよ
いかも

MISRA-Cの検査の道具は無償のものはlintを拡張す
るするとよいかも
TOPPERSのオープンソースはMISRA-C検査をして、
逸脱の手続きを取っている。

2013/12/14


ex2_1
.c
検査結
果:提供
者ヘッ
ダファ
イルに
も逸脱
箇所あ
り。

2013/12/14


逸脱の手続き001
2011年7月8日、担当:小川清、確認：、文書番号
gifu2011001 13: typedef shall be used instead of the basic
逸脱ルー
types
ル
逸脱箇所

193。チェッカで検査し、逸脱一覧を添付。

逸脱理由

利用しない名前を付ける方が誤解を与える
可能性がある。利用していない箇所の数を
数えることで間違いの確認ができる。

対応する
版

2011/7/8以降の版

逸脱手順

前回の検査時の数の変化の理由を確認し、
担当者および確認者が署名またはソースの
先頭に検査人の人名を入れる。
32
2013/12/14


gifu2011002
逸脱ルー 14:use 'signed char' or 'unsigned char'
ル
instead of plain 'char’
逸脱箇所 6。チェッカで検査し、逸脱一覧を添付。
ライブラリなどの複数箇所で利用してい
逸脱理由る。部分的な修正の方が悪影響を与える。
提供者と協議して書き換えるなら全部同
時に実施する。それまでは現状維持。
対応する 2011/7/8以降の版
版
逸脱手順担当者および確認者が署名またはソース
の先頭に検査人の人名を入れる。
2013/12/14


33

gifu2011003
逸脱ルー 69:ellipsis '...' shall not be used
ル

逸脱理由提供側のヘッダファイルで規定している
ため、ルネサスと協議するまで留保。
版
逸脱手順前回の検査時の数の変化の理由を確認し、
担当、確認の2名が署名。
34
2013/12/14


gifu2011004
逸脱ルー 113:struct/union members shall be
ル
named
逸脱理由利用しない値に名前を付けると間違えて
使うといけない。
版
逸脱手順担当者および確認者が署名またはソース
の先頭に検査人の人名を入れる。
35
2013/12/14


前提


動的なメモリ利用は検証が困難
 メモリ確保の時間は可変
 メモリ確保できるかどうかは可変
 メモリ解放がうまくいかずに、メモリ漏れ（
leak)



ポインタ操作の範囲確認が大変
 誤って命令、データを書き換え



CPU間のプログラムの移植の際に問題が発生
 16bit, 32bit
 unsigned, singed
 未規定、未定義，処理系定義
2013/12/14


組み込みシステム
ハードウェアに近いところはＣ言語利用が多い
 アセンブラも混在する場合あり
 C++はじめ他の言語の利用の場合もある
 リアルタイム性が重要でない場合はJAVAなど
 マイコン固有の機能の利用
 マイコン製造元が同時にC言語を出荷
 Cコンパイラ自体、C言語で記述
 Cの標準は特定のCPUを前提
 16bit, 32bit
 安全性（信頼性）, 可搬性（移植性）


2013/12/14


MISRA(Motor Industry Softwre Reliability
Association)


MIRA(欧州の自動車関連団体:MotorIndustry Research
Association)


Development guideline for vehicle based software（ISO TR 15497:)

自動車用ソフトウェアの開発ガイドライン(自動車技術会TP01001)


Guidelines for the use of the C language in vehicle based
software(MISRA-C:1998)

自動車用C言語利用のガイドライン（自動車技術会TP-01002)




C90対応
解説書はSESSAME WG3
MISRA-C:2004(C90対応）

2013/12/14


MISRA-C


C言語規格のPortabilityに対する疑問から、SaferCという
より安全なC言語の書き方の提案があった



自動車業界の要請により自動車業界のコーディングルー
ルとして1998年に発行。HIS（ドイツの自動車業界団
体）がAutomotive SPICE(ISO/IEC 15504), ISO OSEK, ISO
CANなどとともに採用



日本からの意見を含めて第二版を２００４年に発行



C99に対応した第三版を2012年に発行

組込み研修
2013/12/14


組込み開発者におくるMISRA-C
組込みプログラミングの高信頼化ガイド


MISRA-C 研究会(SESSAME WG3),
日本規格協会, 2004



C言語で書いたソフトウェアを他の
CPUに移植する際に問題となる事項
を洗い出し




C言語の規定のあいまいな事項を排
除して、不具合を減らす

参考文献


Safer C
 C言語の落とし穴

2013/12/14


MISRA-C:1998 の概要


127項目の具体的なプログラミングルールと品質サブシ
ステムの解説
静的テストが可能なもの中心
 93の必要と34の推奨




規格(C90)を基準として利用

2013/12/14


MISRA-C:1998の特徴


MISRA-Cの合致は製品ごと



コードの書き方だけでなく、検証方法を要求（合致マト
リックス）



守らない方がよい規則は逸脱の手続き



静的検査ツールによる検出を重視


静的なプログラムを推奨



メモリの動的確保はしない
ポインタの演算はしない

2013/12/14


MISRA-C適用における注意事
項
 ISO/IEC 9899-C languageについて
メトリクスについて
 サブセットの導入
 ルールからの逸脱について
 必要ルールと推奨ルールについて
 ISO/IEC Cの附属書Gについて
 ハードウェア制御と文法再定義について
 副作用と副作用完了点について
 ビットフィールドについて


2013/12/14


MISRA-Cの利用方法


テスト仕様書の一部



品質指標を明確化



グローバルに対応



言語教育に利用



規則の取捨選択




Standing Deviation

静的検査ツールの利用

2013/12/14


規則の分類（カテゴリ）
環境
 文字セット
 コメント
 識別子
 型
 定数
 宣言と定義
 初期化


演算子
 変換
 式
 制御フロー
 関数
 前処理指令
 ポインタと配列
 構造体と共用体
 標準ライブラリ


2013/12/14


課題の段階的詳細化


安全なシステムを構築するために、何ができるか。




大規模化するソフトウェアで、何が必要か。




依存した部分の文書化（対応）

C言語の教育に必要なことは何か。




共通の規則（一部対応）

高級アセンブラとしてCPUに依存した処理が書けるC言語
には何が必要か。




ハードウェアとソフトウェアの責任境界の明確化〔対応）

動くプログラムで教育（応用）

C言語の試験に必要なことは何か。


試験をしてからプログラム||試験のためのプログラムから出発（応
用）

2013/12/14


ハードウェアとソフトウェアの
責任境界の明確化


C言語のPortabilityにハードウェアとの責任境界が見える



CPUごとの試験



Cコンパイラの試験



OSの試験

2013/12/14


プログラムの安全性




コンパイラ、チェッカ（静的解析ツール）で検査可能か
ルールを守らない方が安全な場合は逸脱の手続きを取る
警告が多いと見逃しがでるため、チェッカが逸脱の手続き
と連動しているとよい


警告のノイズ
真の警告ではない
 チェッカの不具合
 逸脱した方が品質が高い
 １つの事象に複数の警告がでる（一番優先順位の高いものだけでよい
かも）




ハードウェアと関係した試験とソフトウェアだけでできる
試験を分ける

2013/12/14


共通の規則（一部対応）


作業標準




スタイルガイド





アプリケーションごと
プログラミング言語ごと

命名規則







ISO TR 15497（MISRA-SA)

OSごと
アプリケーションごと
プログラミング言語ごと

言語に依存したコーディングルール


MISRA-C

2013/12/14


依存した部分の文書化


MISRA－Cの逸脱の手続き




規則を守るのがよいとは限らない
 処理速度の低下
 コードの移植性の低下
規則の逸脱する方がよい場合がある



形式的な規則の適用の危険性
例：
 アセンブラのソースコード
 複数箇所からの戻り

2013/12/14


OSとコンパイラ


C言語がＯＳの存在を想定している場合と、ＯＳがない場
合の２つの標準





ＯＳの存在を想定している場合には、ＯＳの規定が優先





Host環境
Freestanding環境
文字コード、改行、エスケープシーケンス

クロス開発の場合には、開発用ＯＳと対象ＯＳの違いに留
意
コンパイラによる動作の違い

2013/12/14


動くプログラムで教育（応用
）


C Puzzle Book




トリッキーなプログ
ラムの確かめ

C言語の落とし穴


MISRAに対応規則記
述



Cコンパイラ自体のコ
ンパイル



OSのソースのコンパ
イル

2013/12/14


試験をしてからプログラム
試験のためのプログラムから出発


最初は試験プログラムを書く



CPUの試験、Cコンパイラの試験、OSの試験、ライブラ
リの試験から始める



試験プログラムを書くことにより、試験可能なプログラ
ムが書けるようになるかも



可搬性のあるプログラムを書けると再利用可能性が高く
なるかも

2013/12/14


MISRA-C
5 (必須)ISO C標準で使用されてい
環境
る文字や拡張表記のみ使用可能で
1 (必須)全てのコードは ISO 9899
ある.
C標準を満たしていなければな
8 (必須)マルチバイト文字や拡張
らず, 拡張機能は許されない。
文字列リテラルは使用してはなら
ない.
3 (推奨)Cから呼び出されるアセン
ブリ言語の関数は, インライン  コメント
アセンブリ言語のみが含まれ
9 (必須)コメントは入れ子であっては
ならない.
ているCの関数として表現され
なければならず, インラインア 10 (推奨)コード部は‘コメントアウ
ト’してはならない.
センブリ言語は一般のCコード
内に組み込まれてはならない.  関数
82 (推奨)関数は1つの出口しか持って
はならない.


2013/12/14


MISRA-C対応の事前準備


処理系定義(ImplemantationDefinition)を確かめる







コンパイラ、OSを試験する

有効なルールか、現実ありそうなことかを確かめる
 コンパイラによる違い。ＯＳの違い。
ルール間の矛盾がないかを確かめる
 ルール１を守ると、自動的に守れるルール
 ルール１を逸脱しているルール
 ルール（Cの規格の規定）間の優先順位
ＭＩＳＲＡ-Cの教材
 動く事例
 OS、コンパイラのソースをチェック記録
合致マトリックスの作成
 逸脱の手続きの作成


2013/12/14


例題


定義文書の例題は、コンパイルできるソースコードではない。

【サンプル】
[例]
UI_8 var1 = '377'; /* OK: 8進拡張表記377は10進の255 */
UI_8 var2 = '0'; /* OK: 8進拡張表記0は10進の0 */
/* (0は一般にナル文字を表すために使用する) */
UI_8 var3 = 'xFF'; /* OK: 16進拡張表記xffは10進の255 */
UI_8 var4='$';/* NG:$は定義されていない文字なので, 未定義の動作となる */
UI_8 var5='@';/* NG:@は定義されていない文字なので, 未定義の動作となる */
UI_8 var6='C';/* NG: Cは定義されていない拡張表記なので, 未定義の */
/*
動作となる
*/

2013/12/14


例題実行方法
１：Windows/Linux上のコンパイラでのシュミレーション




stdio.hを利用
 printf関数
 main 関数
 処理結果と処理経過を表示
利用したコンパイラ


Microsoft VisualStudio 6.0
 (Cygwin/Linux) GCC 3.1.x/GCC 3.4.X

２：M32C,TOPPERS/jsp


タスクmonitorタスクを利用




Printf相当の関数あり

コンパイラ:ルネサス製N308


MISRA-Cチェッカあり

2013/12/14


misra.h
/******************************
**
* File Name: misrac.h
* Author: kaizen ＠wh.commufa.jp
* Date:
2004.07.20
* Version: 0.09
* Purpose: Test Use Only.
* Distributer:SESSAME WG3/
MISRA-C Study Group sub-group x
*******************************
/
#define _misrac_h_
/* TOPPERSでコンパイルする場合
は _TOPPERS_を宣言しておく。
それ以外はDOS相当のOSでの動作
。*/

2013/12/14

#ifdef _TOPPERS_
#include
"../include/misrac_toppers.h"
#else
#include "../include/misrac_dos.h"
#endif /* _TOPPERS_ */
#ifndef __STDC__
#ifdef DEBUG
#error __STDC__ is not defined.
#else
#define __STDC__ 1
#endif /* DEBUG */
#endif /* __STDC__ */


プログラムの書式
header: author, Create date, Update date
Rule: Rule #, rule(Japanese and English)
Body:
#inclue <misrac.h>
…
Result: Visual Studio (microsoft),
GCC,
N308(Renesas Technology)
Footer: update log

2013/12/14


Rule1.c
*****************************/
* File Name: rule1.c
* Author: kaizen ＠ wh.commufa.jp
* Date:
2004.09.14
* Version: 0.04
* Purpose: Test Use Only.
* Ruel section
Rule1:すべてのコードは ISO/IEC 9899:1990 を
満たしていなければならず, 拡張機能は許され
ない.
* [MISRAC開発ガイドラインテーブル3]
original Rule 1: All code shall conform to
ISO 9899 standard C,with no extensions
permitted.
**************************/
#define _rule1_c_
#include “../include/misrac.h”

2013/12/14

/******************************
* output section
* Visual Studio 6.0 : no error, no warning
main START
far_ptr_arg = 4198400
pointer = 4198912
near_ptr_arg = 4198912
si32_var = -512
main END
* gcc 3.3.1 (cygwin) : no error, no warning
main START
far_ptr_arg = 4198581
pointer = 4198828
near_ptr_arg = 4198828
si32_var = -247
main END
* End: rule1.c (C) MISRA-C Study Group Japan
* add result 2004.07.14
* add end-result and rule 2004.09.14
*****************************/


rule5



* rule 5: ISO C標準で使用している文字や拡張表記のみ使
用可能である.
* original rule 5: Only those characters and escape sequences
which are defined in the ISO C standard shall be used.
UI_8 ui8_var4 = '$'; /* NG: $は定義されていない文字 */
UI_8 ui8_var5 = '@'; /* NG: @は定義されていない文字*/
UI_8 ui8_var6 = ‘C’; /* NG: Cは定義されていない拡張表記 */



Ｃ標準で使用していない文字を認識。


OSで規定すべきこと->OSごとにStandingDeviationを規定するとよい
。

2013/12/14


rule8


Visual Studio では、「適合していないﾜｲﾄﾞ文字列を連結し
ています。」と出たが、gcc(cygwin)では、出なかった。

WC_T wct_ary[] = "abc" L"ABC";
/* NG: 潜在的問題(5)(補足参照) */

2013/12/14


対応ツール


QAC



PolySpace Verifiler



C++TEST



PG Relief C/C++



LDラテストスイート



Review C



SQMlint

2013/12/14


C99未対応(1998/2004年版）


MISRA-C:1998，2004とも//コメントを認めていな
い




コメントの便利さと危険性

C99未対応の理由


C99対応コンパイラが尐ない
 C99に詳細な規定が多い

2013/12/14


MISRA-C1998 まとめ


安全なシステムを構築するための、試験を前提としたコ
ーディング規則



大規模化するソフトウェアで、命名規則と直交できるコ
ーディング規則
CPUに依存した処理の切り分け
C言語の教育にはOS、C言語のソースコードのコンパイ
ルを含む、現実の問題との対応
開発の最初から試験を行う





2013/12/14


MISRA-C1998 課題


MISRA-C 2004


C99未対応
 C99の不要な規定の除外または改定要求


OSの有無、種類によるstanding deviation



16bit, 32bitの固有の問題の識別(8bit, 64bit)



安全性の程度による適用

2013/12/14


MISRA-C(2004)ガイ
ド



SESSAME WG3（MISRA-C研究会）



IEC61508/ISO26262に基づくサブセット、
ガイドラインとして利用



1998年版に対する日本(MISRA-C研究会）
からの意見採用



ルールの厳密化
 1998: (推奨)コード部は‘コメントア
ウト’してはならない.
 2004:コメントの中で/*を書いてはい
けない



ルール数の増加
 厳密にしたため、あいまいなルール
が詳細なルールになる
 不要なルールの削除
多言語のコメントの使用禁止

2013/12/14

©MISRA-C研究会


MISRA-C：品質の視点


品質確認の文書化


規則としての文書化











3.1 処理系定義の動作はすべて文書化
3.2 文字集合及び円コーディング
3.3 整数除算の実装
3.4 #pragma命令
3.5 ビットフィールド
3.6 ライブラリ

逸脱の手続きとしての文書化

品質確保の技法例：




9.1すべての自動変数は用いる前に値を代入しなければならない。
14.1 到達しないコード
21.1 実行時の誤り

2013/12/14


規則9.1 変数の初期値©MISRA-C研究会


すべての自動変数は
用いる前に値を代入
しなければならない
。

組込み研修

void func(void){
int16_t s16_var1 =0;
int_16_t i ;
for(i=0; i<3; i++){
s16_var1+=i;
}
}

(c) saito.naoki, ogawa.kiiyoshi
2013/12/14


規則14.1到達しないコード



到達しないコードがあっては
ならない。
エラー検出のためのコードを
埋める場合には、逸脱の手続
きを取る。


逸脱がある程度あるものが品質
が高い可能性がある。


©MISRA-C研
究会

int_32t s32_inc(int32_t i){
i++;
return i;
print_error(UREAC)；
}

工業標準利用時の経験則（ベス
トプラクティス）

2013/12/14


参考文献
 The Motor Industry Software Reliability Association(1994):Development
Guidelines for Vehicle Base Software,ISBN 0952415607
 The Motor Industry Software Reliability Association(1998):Guidelines for
THE USE Of The language IN Vehicle Based Software ISBN 0952415690
 Guidelines for the use of the C language in critical systems, 2013, ISBN
9781906400-11-8 PDF
 JSAE(2002):JASO/TP-01001 自動車用ソフトウェアの開発ガイドライ
ン,社団法人自動車技術会
 JSAE(2002):JASO/TP-01002 自動車用Ｃ言語利用のガイドライン、社
団法人自動車技術会
 B.W.カーニハン,D.M.リッチー著,石田晴久(訳:1989)プログラミング言
語Ｃ、共立出版
 Ａ.コーニグ著.中村明(訳:2004）Cプログラミングの落とし穴,新紀元
社
 アラン・R. フューアー著, 田中和明・手塚忠則 (訳:2000)C
PuzzleBook,カットシステム
2013/12/14


履歴


2007年6月組込み研修で利用



2007年9月電気関係学会東海支部で発表


課題



項目数の評価
ETSS利用による効果測定



2007年11月組み込みLinux研修



2008年企業向け研修



4.1 2009年SPIN研修



4.2 2009年MISRA-C++研修



4.3 2009年組込み研修

2013/12/14


謝辞
OSC事務局
SESSAMEプロジェクト
TOPPERSプロジェクト

組込中核人材プロジェクト
東陽テクニカ
日本規格協会

ISO/IEC JTC1 SC22 WG14
自動車技術会
トヨタ自動車
C PuzzleBook
Cプログラミングの落とし穴
2013/12/14


MISRA-C2012とISO/IEC 9899:2011 at OSCNagoya2013

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie MISRA-C2012とISO/IEC 9899:2011 at OSCNagoya2013

Ähnlich wie MISRA-C2012とISO/IEC 9899:2011 at OSCNagoya2013 (20)

Mehr von Kiyoshi Ogawa

Mehr von Kiyoshi Ogawa (20)

MISRA-C2012とISO/IEC 9899:2011 at OSCNagoya2013