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

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

2013/12/14

(c)kaizen@wh.com...
今頃C言語?
•

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

•

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

•

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

•

min-CAMLでは直接アセンブラを生成するこ...
よくある意見
Q: プログラミング言語の自動生成をしていて自分でコードを書
かないので関係ない。
A: 自動生成でC言語を使っているとキャストの仕方が不十分で
誤差が拡大したり、0割の発生原因となります。MISRAで
は、自動生成の出力規則も定...
背景


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

CコンパイラもCで記述



CPUの発展を阻害しないように、Cプログラマに不
必要な負荷をかけないように(Cの精神:the spirit of
c)、C言語規格には「未規定」...
C言語の規格


K&R(デファクト)C言語の作者の文書
 アメリカ規格(デジュール)
 ANSI X. 1989(C89):1999版からISO/IECの標準制
定と同時進行
 国際規格:フリースタングィング環境(main無可),
ホ...
JIS C解説(Cの精神) © JIS
1.既存のコードを救うことが重要であり、既存の処理系を保護することは、重
要視しない。
2.可搬性のある原始プログラムが書けるようにする。 (高級アセンブラ的な使
い方による)可搬性がないプログラムを禁止...
The spirit of C, Additional Principles for
C1X
ISO/IEC JTC1 SC22WG14 N1250
12. Trust the programmer, as a goal, is outdate...
動くプログラムで教育(応用
)


C Puzzle Book




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

C言語の落とし穴


MISRAに対応規則記述



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



OSのソースのコンパイ
ル

...
問題1
From C Puzzle book© 1.1
#include <stdio.h>
intmain(intargc, const char * argv[])
{
intx;
x = -3 + 4 * 5 -6; printf("%d...
問題1
From C Puzzle book© 1.1
11
1
0

1

2013/12/14

(c)kaizen@wh.commufa.jp, @kaizen_nagoya
問題2
From C puzzle book ©2.1
#define PRINT(format,x) printf(#x " = %" #format "n",x)
int integer = 5;
char character = '5';...
Defs.h(Cpuzzle book ©)
#ifndef puzzle4_1_defs_h
#define puzzle4_1_defs_h

#include <stdio.h>
#define PR(fmt,val) printf(#v...
Puzzle book ©4.1
#include "defs.h"
intmain(intargc, const char * argv[])
{ intx, y=1, z;
if( y!=0) x=5;
PRINT1(d,x); //(4....
問題4
From Puzzle book© 6.1
#include "defs.h”
inti=0;
intmain(intargc, const char * argv[])
{
auto inti=1;
PRINT1(d,i);//(4....
問題5

From C puzzle book© 7.1
#include "defs.h"
int a[] = {0,1,2,3,4};
intmain(intargc, const char * argv[])
{ inti, *p;
fo...
問題6
Cプログラミングの落とし穴© 1.1章参考
#include "defs.h”
intmain(intargc, const char * argv[])
{

intx = 1, y=0;

if (x = y) PRINT2(d,x...
問題7
Cプログラミングの落とし穴©1.4章参考
#include "defs.h”
intmain(intargc, const char * argv[])
{
// insert code here...
struct {
intpart...
Cプログラミングの落とし穴©3.8章参考
#include "defs.h”
intmain(intargc, const char * argv[])
{
struct {
intpart_number;
char * description...
問題9
Cプログラミングの落とし穴©4.4章参考
#include "defs.h”
intmain(intargc, const char * argv[])
{
printf("%dn",square(1.9));//implicit de...
問題10
Cプログラミングの落とし穴©6.2章参考

#include <stdio.h>
#define absm(x) x>=0?x:-x
intmain(intargc, constchar * argv[]){
inta=1, b=2;...
問題の総括
CPU, コンパイラによって振る舞いの違うコード
が書けてしまう。 ->未規定、未定義、処理系
定義
可読性の悪いプログラムは、差分開発で書いた
本人も間違える可能性がある
影響の範囲が特性しやすいプログラム
MISRA-Cに対応す...
未定義(undefined)と未規定
(unspecified)

3.4.3 undefined behavior: behavior, upon use of a non portable
or erroneous program cons...
課題の背景
自称「Cプログラマ」でC言語規格の存在、内容を
知らない人がいる?

WEBに審議文書を公開している開かれた規格。
http://www.open-std.org/itc1/sc22/wg14/
CPU、コンパイラによって振る舞いが...
全問正解の方
MISRA-C:2012の解説書を差し上げます。
現在、構想。

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

2013/12/14

(c)kaizen@wh.commufa.jp, @kaizen_nagoya
目的


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



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

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

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

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

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

検査しやすいように

2013/12/14

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

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

いろなことができるようになっている。
4. 自動車などの安全性の必要な...
MISRA-Cの確認
CプログラムがCPU、コンパイラで異なる振る舞い
をすることを防ぎ、CPU,コンパイラで同じ仕事をす
るようにする。
部分集合を定義しているので試験のしやすい、可読
性の高いプログラムになる。
検査は複数の手段、道具を使う...
中間まとめ
C言語系のプログラマはC言語の脆弱性をよく理解
するため、無料で手に入るC言語規格を利用しよう
できればCコンパイラを書いてみると良い。
オープンソースのCコンパイラをいじるだけでもよ
いかも

MISRA-Cの検査の道具は無償のも...
ex2_1
.c
検査結
果:提供
者ヘッ
ダファ
イルに
も逸脱
箇所あ
り。

2013/12/14

(c)kaizen@wh.commufa.jp, @kaizen_nagoya
逸脱の手続き001
2011年7月8日、担当:小川清、確認:、文書番号
gifu2011001 13: typedef shall be used instead of the basic
逸脱ルー
types
ル
逸脱箇所

193。チェッカ...
逸脱の手続き002
2011年7月8日、担当:小川清、確認:、文書番号
gifu2011002
逸脱ルー 14:use 'signed char' or 'unsigned char'
ル
instead of plain 'char’
逸脱箇...
逸脱の手続き003
2011年7月8日、担当:小川清、確認:、文書番号
gifu2011003
逸脱ルー 69:ellipsis '...' shall not be used
ル
逸脱箇所 1。チェッカで検査し、逸脱一覧を添付。

逸脱理由 ...
逸脱の手続き004
2011年7月8日、担当:小川清、確認:、文書番号
gifu2011004
逸脱ルー 113:struct/union members shall be
ル
named
逸脱箇所 88。チェッカで検査し、逸脱一覧を添付。
逸...
前提


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



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



...
組み込みシステム
ハードウェアに近いところはC言語利用が多い
 アセンブラも混在する場合あり
 C++はじめ他の言語の利用の場合もある
 リアルタイム性が重要でない場合はJAVAなど
 マイコン固有の機能の利用
 マイコン製造元が同時...
MISRA(Motor Industry Softwre Reliability
Association)


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

Developmen...
MISRA-C


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



自動車業界の要請により自動車業界のコーディングルー
ルとして1998年に発行。HIS(ドイツの自動車業...
組込み開発者におくるMISRA-C
組込みプログラミングの高信頼化ガイド


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



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

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



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

2013/12/14

(c)ka...
MISRA-C:1998の特徴


MISRA-Cの合致は製品ごと



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



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



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

静的なプログ...
MISRA-C適用における注意事
項
 ISO/IEC 9899-C languageについて
メトリクスについて
 サブセットの導入
 ルールからの逸脱について
 必要ルールと推奨ルールについて
 ISO/IEC Cの附属書Gについ...
MISRA-Cの利用方法


テスト仕様書の一部



品質指標を明確化



グローバルに対応



言語教育に利用



規則の取捨選択




Standing Deviation

静的検査ツールの利用

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

演算子
 変換
 式
 制御フロー
 関数
 前処理指令
 ポインタと配列
 構造体と共用体
 標準ライ...
課題の段階的詳細化


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



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



依存した部分の文書化(対応)

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



共通の規則(一部対応)

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

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



CPUごとの試験



Cコンパイラの試験



OSの試験

2013/12/14

(c)kaizen@wh...
プログラムの安全性




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

警告のノイズ
真の警告で...
共通の規則(一部対応)


作業標準




スタイルガイド





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

命名規則







ISO TR 15497(MISRA-SA)

OSごと
アプリケーションごと
...
依存した部分の文書化


MISRA-Cの逸脱の手続き




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

形式的な規則の適用の危険性
例:
 アセンブラのソ...
OSとコンパイラ


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



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




Host環境
Freestanding環境
文字コード、改行、エス...
動くプログラムで教育(応用
)


C Puzzle Book




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

C言語の落とし穴


MISRAに対応規則記
述



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



OSのソースのコンパ
イル

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

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



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



試験プログラムを書くことにより、試験可能なプログラ
ムが書け...
MISRA-C
5 (必須)ISO C標準で使用されてい
環境
る文字や拡張表記のみ使用可能で
1 (必須)全てのコードは ISO 9899
ある.
C標準を満たしていなければな
8 (必須)マルチバイト文字や拡張
らず, 拡張機能は許されない...
MISRA-C対応の事前準備


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






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

有効なルールか、現実ありそうなことかを確かめる
 コンパイラによる違い。OSの違...
例題


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

【サンプル】
[例]
UI_8 var1 = '377'; /* OK: 8進拡張表記377は10進の255 */
UI_8 var2 = '0'; /* OK: 8進拡張...
例題実行方法
1:Windows/Linux上のコンパイラでのシュミレーション




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

Microsoft Visual...
misra.h
/******************************
**
* File Name: misrac.h
* Author: kaizen @wh.commufa.jp
* Date:
2004.07.20
* Vers...
プログラムの書式
header: author, Create date, Update date
Rule: Rule #, rule(Japanese and English)
Body:
#inclue <misrac.h>
…
Resu...
Rule1.c
*****************************/
* File Name: rule1.c
* Author: kaizen @ wh.commufa.jp
* Date:
2004.09.14
* Version:...
rule5



* rule 5: ISO C標準で使用している文字や拡張表記のみ使
用可能である.
* original rule 5: Only those characters and escape sequences
which ...
rule8


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

WC_T wct_ary[] = "abc" L"ABC";
/* NG: 潜在的問題...
対応ツール


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に詳細な規定が多い

2...
MISRA-C1998 まとめ


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



大規模化するソフトウェアで、命名規則と直交できるコ
ーディング規則
CPUに依存した処理の切り分け
C言語の教育にはOS、C言語の...
MISRA-C1998 課題


MISRA-C 2004


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

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



16bit, 32bitの固有の問題の識別(...
MISRA-C(2004)ガイ
ド



SESSAME WG3(MISRA-C研究会)



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



1998年版に対する日本(MISRA-C研究会)
からの...
MISRA-C:品質の視点


品質確認の文書化


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





3.1 処理系定義の動作はすべて文書化
3.2 文字集合及び円コーディング
3.3 整数除算の実装
3.4 #pragma命令
...
規則9.1 変数の初期値©MISRA-C研究会


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

組込み研修

void func(void){
int16_t s16_var1 =0;
int_16_t i ;
for(...
規則14.1到達しないコード



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

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

©MISRA-C研
究会

in...
参考文献
 The Motor Industry Software Reliability Association(1994):Development
Guidelines for Vehicle Base Software,ISBN 095...
履歴


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



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

課題



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



2007年11月組み込みLinux研修



2008年企業向け研修

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

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

ISO/IEC JTC1 SC22 WG14
自動車技術会
トヨタ自動車
C PuzzleBook
Cプログラ...
Upcoming SlideShare
Loading in …5
×

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

2,027 views

Published on

OSC Nagoya 2013 で MISRA-C2012とISO/IEC 9899:2011について演習を出題し、解説した資料。The C Puzzle Book, Cプログラミングの落とし穴を参考にしています。詳細は、それぞれの書籍をごらんくださると幸いです。

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,027
On SlideShare
0
From Embeds
0
Number of Embeds
321
Actions
Shares
0
Downloads
12
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

  1. 1. MISRA-C2012とISO/IEC 9899:2011 MISRA-C-Training ver6 2013.06.20 工学博士・技術士(情報工学) 名古屋市工業研究所 小川清 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  2. 2. 今頃C言語? • CPUが実行するのは機械語。 • 多くのCPU提供者が、CPUとアセンブラ、Cコンパイラを同時に • 実行している内容でよいかどうかをたしかめるのはアセンブラ。 • min-CAMLでは直接アセンブラを生成することによって高速化を • Cを生成すれば、対応CPUが一気に広がる。 • UNIX/LinuxなどのOSはCで記述している。 • CコンパイラをCで記述している。 • アセンブラで書けることなら、Cで書ける。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  3. 3. よくある意見 Q: プログラミング言語の自動生成をしていて自分でコードを書 かないので関係ない。 A: 自動生成でC言語を使っているとキャストの仕方が不十分で 誤差が拡大したり、0割の発生原因となります。MISRAで は、自動生成の出力規則も定義しています。 Q: 試験(test)担当で、直接コードを書かないので関係ない。 A: MISRA-Cは、C言語の部分集合(subset)です。MISRA-Cに対 応すると試験がしやすいコードになります。 Q: 自分は天才プログラマなので一切の規制に反対する。 A: 天才の書いたプログラムを、凡人が間違ったプログラムにし てしまうことがあります。凡人にも理解出来るコードが書 けるのも天才の技の一つとお考えください。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  4. 4. 背景  CPU販売者が言語としてアセンブラとCを提供。  CコンパイラもCで記述  CPUの発展を阻害しないように、Cプログラマに不 必要な負荷をかけないように(Cの精神:the spirit of c)、C言語規格には「未規定」,「未定義」,「処 理系定義」がある。  C言語規格には  OSの存在を前提としたホスト環境(OSあり,mainあ り)と  OSの存在を必ずしも想定していないフリースタンデ ィング環境とがある。OSなくてもよくMainは必要な い。  C言語規格にはOSの一部かもしれないライブラリがある。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  5. 5. C言語の規格  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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  6. 6. JIS C解説(Cの精神) © JIS 1.既存のコードを救うことが重要であり、既存の処理系を保護することは、重 要視しない。 2.可搬性のある原始プログラムが書けるようにする。 (高級アセンブラ的な使 い方による)可搬性がないプログラムを禁止してはならない。 3.(既存の仕様からの)暗黙の意味変更(quiet change)は極力避ける 4.規格は処理系の作成者とプログラマとの間の約束事を記述するものである。 5. 次のCの精神を遵守する. 1. プログラマを信頼する 2. プログラマが必要である事項を行うことを妨げない 3. 言語は小さく、コンパクトに保つ 4. 一つのオペレーティングシステムには唯一の方法を割り当てる たとえ可搬性が保障されない方法であったとしても、実行効率を上げる余地を 残しておく。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  7. 7. 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)kaizen@wh.commufa.jp, @kaizen_nagoya
  8. 8. 動くプログラムで教育(応用 )  C Puzzle Book   トリッキーなプログラ ムの確かめ C言語の落とし穴  MISRAに対応規則記述  Cコンパイラ自体のコン パイル  OSのソースのコンパイ ル  TOPPERS 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  9. 9. 問題1 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  10. 10. 問題1 From C Puzzle book© 1.1 11 1 0 1 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  11. 11. 問題2 From C puzzle book ©2.1 #define PRINT(format,x) printf(#x " = %" #format "n",x) int integer = 5; char character = '5'; char * string = "5”; intmain(intargc, const char * argv[]) { 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  12. 12. 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  13. 13. Puzzle book ©4.1 #include "defs.h" intmain(intargc, const char * argv[]) { 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 問題3 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  14. 14. 問題4 From Puzzle book© 6.1 #include "defs.h” inti=0; intmain(intargc, const char * argv[]) { 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  15. 15. 問題5 From C puzzle book© 7.1 #include "defs.h" int a[] = {0,1,2,3,4}; intmain(intargc, const char * argv[]) { 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  16. 16. 問題6 Cプログラミングの落とし穴© 1.1章参考 #include "defs.h” intmain(intargc, const char * argv[]) { 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  17. 17. 問題7 Cプログラミングの落とし穴©1.4章参考 #include "defs.h” intmain(intargc, const char * argv[]) { // 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  18. 18. Cプログラミングの落とし穴©3.8章参考 #include "defs.h” intmain(intargc, const char * argv[]) { struct { intpart_number; char * description; } parttab[]={ 046, "left-handed widget", 047, "right-handed widget", 125, "frammis" }; 問題8 for (inti=0; i<3; i++){ PRINT1(d, parttab[i].part_number); NL;PRINT1(s, parttab[i].description); } return 0; } 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  19. 19. 問題9 Cプログラミングの落とし穴©4.4章参考 #include "defs.h” intmain(intargc, const char * argv[]) { 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  20. 20. 問題10 Cプログラミングの落とし穴©6.2章参考 #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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  21. 21. 問題の総括 CPU, コンパイラによって振る舞いの違うコード が書けてしまう。 ->未規定、未定義、処理系 定義 可読性の悪いプログラムは、差分開発で書いた 本人も間違える可能性がある 影響の範囲が特性しやすいプログラム MISRA-Cに対応すると関数プログラミングに近 づく 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  22. 22. 未定義(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)kaizen@wh.commufa.jp, @kaizen_nagoya
  23. 23. 課題の背景 自称「Cプログラマ」でC言語規格の存在、内容を 知らない人がいる? WEBに審議文書を公開している開かれた規格。 http://www.open-std.org/itc1/sc22/wg14/ CPU、コンパイラによって振る舞いが違うコードの 存在を知らない人がいる プログラマが何でもできようにしてあるが、何をし たらいいかの知見をためるのがMISRA-C http://researchmap.jp/kaizen/MISRA-C/ 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  24. 24. 全問正解の方 MISRA-C:2012の解説書を差し上げます。 現在、構想。 MISRA-C 2013研究会 解説書を作ろう 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  25. 25. 目的  異なるCPUでコンパイルしたときに同じ振舞をする 安全なシステムを構築するための試験,証明。  大規模化するソフトウェアの構造化。  CPUに依存した処理が書ける(高級アセンブラ)。   C言語教育に必要なこと。  Cコンパイラを理解する(改良できる):C言語で記述  OSを理解する(改良できる):C言語で記述  ネットワークを理解する(改良できる):C言語で記述  C言語試験、証明 空間(集合)の制限:MISRA-C  時間の検証:HDLならSTARC RTL設計スタイルガイド  2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  26. 26. C2011で嬉しいこと Allignを規定した GCCとObjective-Cでallignが違う。 Min-CAMLのコンパイルで失敗中。 Min-CAMLはアセンブラを出力している。 C言語を出力するようにすれば対応CPUが増える。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  27. 27. MISRA-C 2012で嬉しいこ と C90, C99に両対応 //コメント、bool定義が基本。 規則の大分類を入れより体系的に Directive(指令) Rule(規則) 検査しやすいように 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  28. 28. ここで確認。 1. C言語規格の審議過程(規格相当文書を含む)が 閲覧できる 2. JIS 規格が無償で閲覧できる。 3. C言語には、Cの精神、技術の発展のため、いろ いろなことができるようになっている。 4. 自動車などの安全性の必要なプログラムは、で きるだけ自由をなくして、なるべく唯一の方法 をえらぶように習慣づける 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  29. 29. MISRA-Cの確認 CプログラムがCPU、コンパイラで異なる振る舞い をすることを防ぎ、CPU,コンパイラで同じ仕事をす るようにする。 部分集合を定義しているので試験のしやすい、可読 性の高いプログラムになる。 検査は複数の手段、道具を使うことを推奨している。 (合致表) 規則を守ることが大事なのではなく、なぜそうする とよいかどうかの判断ができる。規則を守ると 言語のFailure Modeをさける規則を列記しているの でソフトウェアFMEAの作業の最初として役立つ。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  30. 30. 中間まとめ C言語系のプログラマはC言語の脆弱性をよく理解 するため、無料で手に入るC言語規格を利用しよう できればCコンパイラを書いてみると良い。 オープンソースのCコンパイラをいじるだけでもよ いかも MISRA-Cの検査の道具は無償のものはlintを拡張す るするとよいかも TOPPERSのオープンソースはMISRA-C検査をして、 逸脱の手続きを取っている。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  31. 31. ex2_1 .c 検査結 果:提供 者ヘッ ダファ イルに も逸脱 箇所あ り。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  32. 32. 逸脱の手続き001 2011年7月8日、担当:小川清、確認:、文書番号 gifu2011001 13: typedef shall be used instead of the basic 逸脱ルー types ル 逸脱箇所 193。チェッカで検査し、逸脱一覧を添付。 逸脱理由 利用しない名前を付ける方が誤解を与える 可能性がある。利用していない箇所の数を 数えることで間違いの確認ができる。 対応する 版 2011/7/8以降の版 逸脱手順 前回の検査時の数の変化の理由を確認し、 担当者および確認者が署名またはソースの 先頭に検査人の人名を入れる。 32 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  33. 33. 逸脱の手続き002 2011年7月8日、担当:小川清、確認:、文書番号 gifu2011002 逸脱ルー 14:use 'signed char' or 'unsigned char' ル instead of plain 'char’ 逸脱箇所 6。チェッカで検査し、逸脱一覧を添付。 ライブラリなどの複数箇所で利用してい 逸脱理由 る。部分的な修正の方が悪影響を与える。 提供者と協議して書き換えるなら全部同 時に実施する。それまでは現状維持。 対応する 2011/7/8以降の版 版 前回の検査時の数の変化の理由を確認し、 逸脱手順 担当者および確認者が署名またはソース の先頭に検査人の人名を入れる。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya 33
  34. 34. 逸脱の手続き003 2011年7月8日、担当:小川清、確認:、文書番号 gifu2011003 逸脱ルー 69:ellipsis '...' shall not be used ル 逸脱箇所 1。チェッカで検査し、逸脱一覧を添付。 逸脱理由 提供側のヘッダファイルで規定している ため、ルネサスと協議するまで留保。 対応する 2011/7/8以降の版 版 逸脱手順 前回の検査時の数の変化の理由を確認し、 担当、確認の2名が署名。 34 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  35. 35. 逸脱の手続き004 2011年7月8日、担当:小川清、確認:、文書番号 gifu2011004 逸脱ルー 113:struct/union members shall be ル named 逸脱箇所 88。チェッカで検査し、逸脱一覧を添付。 逸脱理由 利用しない値に名前を付けると間違えて 使うといけない。 対応する 2011/7/8以降の版 版 前回の検査時の数の変化の理由を確認し、 逸脱手順 担当者および確認者が署名またはソース の先頭に検査人の人名を入れる。 35 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  36. 36. 前提  動的なメモリ利用は検証が困難  メモリ確保の時間は可変  メモリ確保できるかどうかは可変  メモリ解放がうまくいかずに、メモリ漏れ( leak)  ポインタ操作の範囲確認が大変  誤って命令、データを書き換え  CPU間のプログラムの移植の際に問題が発生  16bit, 32bit  unsigned, singed  未規定、未定義,処理系定義 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  37. 37. 組み込みシステム ハードウェアに近いところはC言語利用が多い  アセンブラも混在する場合あり  C++はじめ他の言語の利用の場合もある  リアルタイム性が重要でない場合はJAVAなど  マイコン固有の機能の利用  マイコン製造元が同時にC言語を出荷  Cコンパイラ自体、C言語で記述  Cの標準は特定のCPUを前提  16bit, 32bit  安全性(信頼性), 可搬性(移植性)  2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  38. 38. 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  39. 39. MISRA-C  C言語規格のPortabilityに対する疑問から、SaferCという より安全なC言語の書き方の提案があった  自動車業界の要請により自動車業界のコーディングルー ルとして1998年に発行。HIS(ドイツの自動車業界団 体)がAutomotive SPICE(ISO/IEC 15504), ISO OSEK, ISO CANなどとともに採用  日本からの意見を含めて第二版を2004年に発行  C99に対応した第三版を2012年に発行 組込み研修 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  40. 40. 組込み開発者におくるMISRA-C 組込みプログラミングの高信頼化ガイド  MISRA-C 研究会(SESSAME WG3), 日本規格協会, 2004  C言語で書いたソフトウェアを他の CPUに移植する際に問題となる事項 を洗い出し   C言語の規定のあいまいな事項を排 除して、不具合を減らす 参考文献  Safer C  C言語の落とし穴 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  41. 41. MISRA-C:1998 の概要  127項目の具体的なプログラミングルールと品質サブシ ステムの解説 静的テストが可能なもの中心  93の必要と34の推奨   規格(C90)を基準として利用 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  42. 42. MISRA-C:1998の特徴  MISRA-Cの合致は製品ごと  コードの書き方だけでなく、検証方法を要求(合致マト リックス)  守らない方がよい規則は逸脱の手続き  静的検査ツールによる検出を重視  静的なプログラムを推奨   メモリの動的確保はしない ポインタの演算はしない 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  43. 43. MISRA-C適用における注意事 項  ISO/IEC 9899-C languageについて メトリクスについて  サブセットの導入  ルールからの逸脱について  必要ルールと推奨ルールについて  ISO/IEC Cの附属書Gについて  ハードウェア制御と文法再定義について  副作用と副作用完了点について  ビットフィールドについて  2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  44. 44. MISRA-Cの利用方法  テスト仕様書の一部  品質指標を明確化  グローバルに対応  言語教育に利用  規則の取捨選択   Standing Deviation 静的検査ツールの利用 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  45. 45. 規則の分類(カテゴリ) 環境  文字セット  コメント  識別子  型  定数  宣言と定義  初期化  演算子  変換  式  制御フロー  関数  前処理指令  ポインタと配列  構造体と共用体  標準ライブラリ  2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  46. 46. 課題の段階的詳細化  安全なシステムを構築するために、何ができるか。   大規模化するソフトウェアで、何が必要か。   依存した部分の文書化(対応) C言語の教育に必要なことは何か。   共通の規則(一部対応) 高級アセンブラとしてCPUに依存した処理が書けるC言語 には何が必要か。   ハードウェアとソフトウェアの責任境界の明確化〔対応) 動くプログラムで教育(応用) C言語の試験に必要なことは何か。  試験をしてからプログラム||試験のためのプログラムから出発(応 用) 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  47. 47. ハードウェアとソフトウェアの 責任境界の明確化  C言語のPortabilityにハードウェアとの責任境界が見える  CPUごとの試験  Cコンパイラの試験  OSの試験 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  48. 48. プログラムの安全性    コンパイラ、チェッカ(静的解析ツール)で検査可能か ルールを守らない方が安全な場合は逸脱の手続きを取る 警告が多いと見逃しがでるため、チェッカが逸脱の手続き と連動しているとよい  警告のノイズ 真の警告ではない  チェッカの不具合  逸脱した方が品質が高い  1つの事象に複数の警告がでる(一番優先順位の高いものだけでよい かも)   ハードウェアと関係した試験とソフトウェアだけでできる 試験を分ける 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  49. 49. 共通の規則(一部対応)  作業標準   スタイルガイド    アプリケーションごと プログラミング言語ごと 命名規則     ISO TR 15497(MISRA-SA) OSごと アプリケーションごと プログラミング言語ごと 言語に依存したコーディングルール  MISRA-C 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  50. 50. 依存した部分の文書化  MISRA-Cの逸脱の手続き   規則を守るのがよいとは限らない  処理速度の低下  コードの移植性の低下 規則の逸脱する方がよい場合がある   形式的な規則の適用の危険性 例:  アセンブラのソースコード  複数箇所からの戻り 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  51. 51. OSとコンパイラ  C言語がOSの存在を想定している場合と、OSがない場 合の2つの標準    OSの存在を想定している場合には、OSの規定が優先    Host環境 Freestanding環境 文字コード、改行、エスケープシーケンス クロス開発の場合には、開発用OSと対象OSの違いに留 意 コンパイラによる動作の違い 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  52. 52. 動くプログラムで教育(応用 )  C Puzzle Book   トリッキーなプログ ラムの確かめ C言語の落とし穴  MISRAに対応規則記 述  Cコンパイラ自体のコ ンパイル  OSのソースのコンパ イル 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  53. 53. 試験をしてからプログラム 試験のためのプログラムから出発  最初は試験プログラムを書く  CPUの試験、Cコンパイラの試験、OSの試験、ライブラ リの試験から始める  試験プログラムを書くことにより、試験可能なプログラ ムが書けるようになるかも  可搬性のあるプログラムを書けると再利用可能性が高く なるかも 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  54. 54. MISRA-C 5 (必須)ISO C標準で使用されてい 環境 る文字や拡張表記のみ使用可能で 1 (必須)全てのコードは ISO 9899 ある. C標準を満たしていなければな 8 (必須)マルチバイト文字や拡張 らず, 拡張機能は許されない。 文字列リテラルは使用してはなら ない. 3 (推奨)Cから呼び出されるアセン ブリ言語の関数は, インライン  コメント アセンブリ言語のみが含まれ 9 (必須)コメントは入れ子であっては ならない. ているCの関数として表現され なければならず, インラインア 10 (推奨)コード部は‘コメントアウ ト’してはならない. センブリ言語は一般のCコード 内に組み込まれてはならない.  関数 82 (推奨)関数は1つの出口しか持って はならない.  2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  55. 55. MISRA-C対応の事前準備  処理系定義(ImplemantationDefinition)を確かめる     コンパイラ、OSを試験する 有効なルールか、現実ありそうなことかを確かめる  コンパイラによる違い。OSの違い。 ルール間の矛盾がないかを確かめる  ルール1を守ると、自動的に守れるルール  ルール1を逸脱しているルール  ルール(Cの規格の規定)間の優先順位 MISRA-Cの教材  動く事例  OS、コンパイラのソースをチェック記録 合致マトリックスの作成  逸脱の手続きの作成  2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  56. 56. 例題  定義文書の例題は、コンパイルできるソースコードではない。 【サンプル】 [例] 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  57. 57. 例題実行方法 1:Windows/Linux上のコンパイラでのシュミレーション   stdio.hを利用  printf関数  main 関数  処理結果と処理経過を表示 利用したコンパイラ  Microsoft VisualStudio 6.0  (Cygwin/Linux) GCC 3.1.x/GCC 3.4.X 2:M32C,TOPPERS/jsp  タスクmonitorタスクを利用   Printf相当の関数あり コンパイラ:ルネサス製N308  MISRA-Cチェッカあり 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  58. 58. 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__ */ (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  59. 59. プログラムの書式 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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  60. 60. 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 *****************************/ (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  61. 61. 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は定義されていない拡張表記 */  C標準で使用していない文字を認識。  OSで規定すべきこと->OSごとにStandingDeviationを規定するとよい 。 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  62. 62. rule8  Visual Studio では、「適合していないワイド文字列を連結し ています。」と出たが、gcc(cygwin)では、出なかった。 WC_T wct_ary[] = "abc" L"ABC"; /* NG: 潜在的問題(5)(補足参照) */ 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  63. 63. 対応ツール  QAC  PolySpace Verifiler  C++TEST  PG Relief C/C++  LDラテストスイート  Review C  SQMlint 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  64. 64. C99未対応(1998/2004年版)  MISRA-C:1998,2004とも//コメントを認めていな い   コメントの便利さと危険性 C99未対応の理由  C99対応コンパイラが尐ない  C99に詳細な規定が多い 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  65. 65. MISRA-C1998 まとめ  安全なシステムを構築するための、試験を前提としたコ ーディング規則  大規模化するソフトウェアで、命名規則と直交できるコ ーディング規則 CPUに依存した処理の切り分け C言語の教育にはOS、C言語のソースコードのコンパイ ルを含む、現実の問題との対応 開発の最初から試験を行う    2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  66. 66. MISRA-C1998 課題  MISRA-C 2004  C99未対応  C99の不要な規定の除外または改定要求  OSの有無、種類によるstanding deviation  16bit, 32bitの固有の問題の識別(8bit, 64bit)  安全性の程度による適用 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  67. 67. MISRA-C(2004)ガイ ド  SESSAME WG3(MISRA-C研究会)  IEC61508/ISO26262に基づくサブセット、 ガイドラインとして利用  1998年版に対する日本(MISRA-C研究会) からの意見採用  ルールの厳密化  1998: (推奨)コード部は‘コメントア ウト’してはならない.  2004:コメントの中で/*を書いてはい けない  ルール数の増加  厳密にしたため、あいまいなルール が詳細なルールになる  不要なルールの削除 多言語のコメントの使用禁止 2013/12/14 ©MISRA-C研究会 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  68. 68. MISRA-C:品質の視点  品質確認の文書化  規則としての文書化         3.1 処理系定義の動作はすべて文書化 3.2 文字集合及び円コーディング 3.3 整数除算の実装 3.4 #pragma命令 3.5 ビットフィールド 3.6 ライブラリ 逸脱の手続きとしての文書化 品質確保の技法例:    9.1すべての自動変数は用いる前に値を代入しなければならない。 14.1 到達しないコード 21.1 実行時の誤り 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  69. 69. 規則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 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  70. 70. 規則14.1到達しないコード   到達しないコードがあっては ならない。 エラー検出のためのコードを 埋める場合には、逸脱の手続 きを取る。  逸脱がある程度あるものが品質 が高い可能性がある。  ©MISRA-C研 究会 int_32t s32_inc(int32_t i){ i++; return i; print_error(UREAC); } 工業標準利用時の経験則(ベス トプラクティス) 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  71. 71. 参考文献  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 自動車用C言語利用のガイドライン、社 団法人自動車技術会  B.W.カーニハン,D.M.リッチー著,石田晴久(訳:1989)プログラミング言 語C、共立出版  A.コーニグ著.中村明(訳:2004)Cプログラミングの落とし穴,新紀元 社  アラン・R. フューアー 著, 田中 和明・手塚 忠則 (訳:2000)C PuzzleBook,カットシステム 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  72. 72. 履歴  2007年6月組込み研修で利用  2007年9月電気関係学会東海支部で発表  課題   項目数の評価 ETSS利用による効果測定  2007年11月組み込みLinux研修  2008年企業向け研修  4.1 2009年SPIN研修  4.2 2009年MISRA-C++研修  4.3 2009年組込み研修 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
  73. 73. 謝辞 OSC事務局 SESSAMEプロジェクト TOPPERSプロジェクト 組込中核人材プロジェクト 東陽テクニカ 日本規格協会 ISO/IEC JTC1 SC22 WG14 自動車技術会 トヨタ自動車 C PuzzleBook Cプログラミングの落とし穴 2013/12/14 (c)kaizen@wh.commufa.jp, @kaizen_nagoya

×