Who enjoy a coding standard? We propose programmer should be enjoy a coding standard. Nobody may not insist to write code non free. Programmer can write codes freely. Before reviews, beautifier, static analysis and naming check tools should be useful.
53. namespace M {
class B { };
}
namespace N {
class Y : public M::B {
class X {
int a[i];
};
};
}
int main() {
cout<< msg << endl;
return EXIT_SUCCESS;
}
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
65. Brian W. Kernighan and
Dennis M. Ritchie(K&R)
利点
簡単に動くソフトウェア
main(){
printf(“Hello World!¥n”);
}
罠
2つとも可変引数関数()
初版1978
日本語版には「UNIX流プログラム書法と作法」
ANSI-C対応版1988
#include <stdio.h>
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
66. C言語と規約の歴史
1978 K&R The C programming Language(Bell Lab.)
1982 The C Puzzle Book(Bell Lab.)
1988 K&R ver.2(ANSI-C version: Bell Lab.
1989 C tarps and pit falls(Bell Lab.)
1989 ANSI-C:1989
1990 ISO/IEC 9899(same as ANSI-C)
1995 Safer C
1995 ISO/IEC 9899 Amd1
1998 MISRA C:1998
1999 ISO/IEC 9899
2004 MISRA C:2004
2011 ISO/IEC 9899
2012 MISRA C:2012
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
67. The C Puzzle BOOK
by Alan R. Feuer
利点
ソースコードと出力例・解説
がある。
Bit幅などにCの処理系による
違いがわかる。
初版1982, 改訂版1998
Bell Laboratory
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
68. C traps and pitfalls
by Andrew Koenig
利点
プログラマが遭遇する怪しいプログラム
例
MISRA Cで参照・引用
if (x = y) foo();
Newsletter :ACM SIGPLAN Notices:
http://www.literateprogramming.com/
ctraps.pdf The C Puzzle Bookが参考文献。
1995
Bell Laboratory2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
69. Safer C developing software
for high-integrity and safety-
critical systems.by Les Hatton
規格の未定義、未規定、処理
系定義による動作の違いの
可能性を指摘
処理系による動作の違いを避
けるプログラミング
1995
http://www.leshatton.org
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
70. MISRA C-Training Kit内訳
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
The C Puzzle Book/C traps and pit falls
ISO/IEC 9899:2011(1999, 1995, 1990)
ESCR
ISO/IEC TS 17961
CERTC
MISRA C2012, 2004, 1998
76. 動くプログラムで教育
l The C Puzzle Book
l 危険なプログラムの確かめ
l Cプログラミングの落とし穴
l MISRAに対応規則記述
l Cコンパイラ自体のコンパイル
l OSのソースのコンパイル
l TOPPERSのMISRA C対応
l 国際規格・コーディン
グ標準の例(sample)の
コンパイル
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
91. C言語の規格
l K&R(de facto)C言語作者の文書
l アメリカ規格(de jure)
l ANSI X. 1989(C89):1999版からISO/IECと同時進行
l 国際規格:フリースタングィング環境(main無可),ホス
ト環境(main引数有)
l ISO/IEC 9899:1990(C90=ANSI C89)
l AMD 1995
l ISO/IEC 9899:1999(C99)
l ISO/IEC 9899:2011(C2011)
l 国内規格
l JIS X 3010:1993(C90), JIS X 3010:2004(C99)
l 最新版はwww.jisc.go.jpで無償で閲覧可
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
98. ここまでのまとめ
The C puzzle BOOK, C Trap and pitfallsなどの困ったプ
ログラムを排除する規約
国際規格ISO/IEC 9899の例をコンパイル
Undefined, Unspecified, Implementation defined
CERTCとTS17961は姉妹
Library, OSとの境界に着目
MISRA C
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
102. 背景
l CPU販売者が言語としてアセンブラとCを提供。
l CコンパイラもCで記述
l CPUの発展を阻害しないように、Cプログラマに不必要な
負荷をかけないように(Cの精神:the spirit of c)、C言語
規格には「未規定」,「未定義」,「処理系定義」がある。
l C言語規格には
l OSの存在を前提としたホスト環境(OSあり,mainあり)と
l OSの存在を必ずしも想定していないフリースタンディング
環境とがある。OSなくてもよくMainは必要ない。
l C言語規格にはOSの一部かもしれないライブラリがある。
l OSもCで記述
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
104. 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
safety programming 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.
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
105. 未定義(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 arguments
to a function are evaluated.
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
107. 目的
l 異なるCPUでコンパイルしたときに同じ振舞をする
l 安全なシステムを構築するための試験,証明。
l 大規模化するソフトウェアの構造化。
l CPUに依存した処理が書ける(高級アセンブラ)。
l C言語教育に必要なこと。
l Cコンパイラを理解する(改良できる):C言語で記述
l OSを理解する(改良できる):C言語で記述
l ネットワークを理解する(改良できる):C言語で記述
l C言語試験、証明
l 空間(集合)の制限:MISRA C
l 時間の検証:HDLならSTARC RTL設計スタイルガイド
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
122. MISRA(Motor Industry Softwre Reliability
Association)
l MIRA(欧州の自動車関連団体:Motor Industry Research
Association)
l Development guideline for vehicle based software(ISO TR 15497:)
自動車用ソフトウェアの開発ガイドライン(自動車技術会
TP-01001)
l Guidelines for the use of the C language in vehicle based
software(MISRA C:1998)
自動車用C言語利用のガイドライン(自動車技術会TP-01002)
l C90対応
l 解説書はSESSAME WG3
l MISRA C:2004(C90対応)
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
123. MISRA C
l C言語規格のPortabilityに対する疑問から、SaferCというより
安全なC言語の書き方の提案があった
l 自動車業界の要請により自動車業界のコーディングルール
として1998年に発行。HIS(ドイツの自動車業界団体)が
Automotive SPICE(ISO/IEC 15504), ISO OSEK, ISO CANな
どとともに採用
l 日本からの意見を含めて第二版を2004年に発行
l C99に対応した第三版を2012年に発行
(c)kaizen@wh.commufa.jp, @kaizen_nagoya組込み研修
2018/05/19
124. 組込み開発者におくるMISRA C
組込みプログラミングの高信頼化ガイド
l MISRA C 研究会(SESSAME WG3),
日本規格協会, 2004
l C言語で書いたソフトウェアを他の
CPUに移植する際に問題となる事項
を洗い出し
l C言語の規定のあいまいな事項を排
除して、不具合を減らす
l 参考文献
l Safer C
l C言語の落とし穴
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
125. MISRA C:1998 の概要
l 127項目の具体的なプログラミングルールと品質サブシステ
ムの解説
l 静的テストが可能なもの中心
l 93の必要と34の推奨
l 規格(C90)を基準として利用
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
126. MISRA C:1998の特徴
l MISRA Cの合致は製品ごと
l コードの書き方だけでなく、検証方法を要求(合致マトリック
ス)
l 守らない方がよい規則は逸脱の手続き
l 静的検査ツールによる検出を重視
l 静的なプログラムを推奨
l メモリの動的確保はしない
l ポインタの演算はしない
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
127. MISRA C適用における注意事項
l ISO/IEC 9899-C languageについて
l メトリクスについて
l サブセットの導入
l ルールからの逸脱について
l 必要ルールと推奨ルールについて
l ISO/IEC Cの附属書Gについて
l ハードウェア制御と文法再定義について
l 副作用と副作用完了点について
l ビットフィールドについて
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
128. MISRA Cの利用方法
l テスト仕様書の一部
l 品質指標を明確化
l グローバルに対応
l 言語教育に利用
l 規則の取捨選択
l Standing Deviation
l 静的検査ツールの利用
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
129. 規則の分類(カテゴリ)
l 環境
l 文字セット
l コメント
l 識別子
l 型
l 定数
l 宣言と定義
l 初期化
l 演算子
l 変換
l 式
l 制御フロー
l 関数
l 前処理指令
l ポインタと配列
l 構造体と共用体
l 標準ライブラリ
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
130. 課題の段階的詳細化
l 安全なシステムを構築するために、何ができるか。
l ハードウェアとソフトウェアの責任境界の明確化〔対応)
l 大規模化するソフトウェアで、何が必要か。
l 共通の規則(一部対応)
l 高級アセンブラとしてCPUに依存した処理が書けるC言語には
何が必要か。
l 依存した部分の文書化(対応)
l C言語の教育に必要なことは何か。
l 動くプログラムで教育(応用)
l C言語の試験に必要なことは何か。
l 試験をしてからプログラム||試験のためのプログラムから出発(応用)
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
132. プログラムの安全性
l コンパイラ、チェッカ(静的解析ツール)で検査可能か
l ルールを守らない方が安全な場合は逸脱の手続きを取る
l 警告が多いと見逃しがでるため、チェッカが逸脱の手続きと連
動しているとよい
l 警告のノイズ
l 真の警告ではない
l チェッカの不具合
l 逸脱した方が品質が高い
l 1つの事象に複数の警告がでる(一番優先順位の高いものだけでよいか
も)
l ハードウェアと関係した試験とソフトウェアだけでできる試験を
分ける
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
133. 共通の規則(一部対応)
l 機能安全
l ISO 26262
l 作業標準
l ISO TR 15497(MISRA SA)
l スタイルガイド
l アプリケーションごと
l プログラミング言語ごと
l 命名規則
l OSごと
l アプリケーションごと
l プログラミング言語ごと
l 言語に依存したコーディングルール
l MISRA C
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
134. 依存した部分の文書化
l MISRA Cの逸脱の手続き
l 規則を守るのがよいとは限らない
l 処理速度の低下
l コードの移植性の低下
l 規則の逸脱する方がよい場合がある
l 形式的な規則の適用の危険性
l 例:
l アセンブラのソースコード
l 複数箇所からの戻り
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
137. MISRA C
l 環境
1 (必須)全てのコードは ISO 9899 C
標準を満たしていなければなら
ず, 拡張機能は許されない 。
3 (推奨)Cから呼び出される アセン
ブリ言語の関数は, インラインア
センブリ言語のみが含まれてい
るCの関数として表現されなけれ
ばならず, インラインアセンブリ言
語は一般のCコード内に組み込
まれてはならない.
5 (必須)ISO C標準で使用されてい
る文字や拡張表記のみ使用可能で
ある.
8 (必須)マルチバイト文字や拡張文
字列リテラルは使用してはならない.
l コメント
9 (必須)コメントは入れ子であってはな
らない.
10 (推奨)コード部は‘コメントアウト’して
はならない.
l 関数
82 (推奨)関数は1つの出口しか持って
はならない.
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
138. MISRA C対応の事前準備
l 処理系定義(ImplemantationDefinition)を確かめる
l コンパイラ、OSを試験する
l 有効なルールか、現実ありそうなことかを確かめる
l コンパイラによる違い。OSの違い。
l ルール間の矛盾がないかを確かめる
l ルール1を守ると、自動的に守れるルール
l ルール1を逸脱しているルール
l ルール(Cの規格の規定)間の優先順位
l MISRA Cの教材
l 動く事例
l OS、コンパイラのソースをチェック記録
l 合致マトリックスの作成
l 逸脱の手続きの作成
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
140. 例題実行方法
1:Windows/Linux上のコンパイラでのシュミレーション
l stdio.hを利用
l printf関数
l main 関数
l 処理結果と処理経過を表示
l 利用したコンパイラ
l Microsoft VisualStudio 6.0
l (Cygwin/Linux) GCC 3.1.x/GCC 3.4.X
2:M32C,TOPPERS/jsp
l タスクmonitorタスクを利用
l Printf相当の関数あり
l コンパイラ:ルネサス製N308
l MISRA Cチェッカあり
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
141. 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での動
作。*/
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
#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__ */
143. 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”
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
/******************************
* 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
*****************************/
144. Rule.5
u * rule 5: ISO C標準で使用している文字や拡張表記のみ使用
可能である.
u * 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は定義されていない拡張表記 */
l C標準で使用していない文字を認識。
l OSで規定すべきこと->OSごとにStanding Deviationを規定するとよい。
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
146. 対応ツール
l QAC
l LDRAツールスイート
l PG Relief C/C++
l PolySpace Verifiler
l C++TEST
l Review C
l SQMlint
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
147. MISRA C1998 まとめ
l 安全なシステムを構築するための、試験を前提としたコー
ディング規則
l 大規模化するソフトウェアで、命名規則と直交できるコーディ
ング規則
l CPUに依存した処理の切り分け
l C言語の教育にはOS、C言語のソースコードのコンパイルを
含む、現実の問題との対応
l 開発の最初から試験を行う
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
148. MISRA C1998 課題
l MISRA C 2004
l C99未対応
l C99の不要な規定の除外または改定要求
l OSの有無、種類によるstanding deviation
l 16bit, 32bitの固有の問題の識別(8bit, 64bit)
l 安全性の程度による適用
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
150. MISRA C:品質の視点
l 品質確認の文書化
l 規則としての文書化
l 3.1 処理系定義の動作はすべて文書化
l 3.2 文字集合及び円コーディング
l 3.3 整数除算の実装
l 3.4 #pragma命令
l 3.5 ビットフィールド
l 3.6 ライブラリ
l 逸脱の手続きとしての文書化
l 品質確保の技法例:
l 9.1すべての自動変数は用いる前に値を代入しなければならない。
l 14.1 到達しないコード
l 21.1 実行時の誤り
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
154. 2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya
主要参考文献
u The Motor Industry Software Reliability Association(1994):Development
Guidelines for Vehicle Base Software,ISBN 0952415607
u The Motor Industry Software Reliability Association(1998):Guidelines for
THE USE Of The language IN Vehicle Based Software ISBN 0952415690
u Guidelines for the use of the C language in critical systems, 2013, ISBN
9781906400-11-8 PDF
u JSAE(2002):JASO/TP-01001 自動車用ソフトウェアの開発ガイドライン,社
団法人自動車技術会
u JSAE(2002):JASO/TP-01002 自動車用C言語利用のガイドライン、社団法
人自動車技術会
u B.W.カーニハン,D.M.リッチー著,石田晴久(訳:1989)プログラミング言語C、
共立出版
u A.コーニグ著.中村明(訳:2004)Cプログラミングの落とし穴,新紀元社
u アラン・R. フューアー 著, 田中 和明・手塚 忠則 (訳:2000) The C
PuzzleBook,カットシステム
155. 履歴
l 2.0 2004年7月CEST 自動車業界の C コーディング標準 MISRA C について
l 2.1 2004年9月電気関係学会東海支部
l 2.2 2005年3月日本科学技術連盟24回. 株ヴィッツ服部博行氏
l 3.0 2007年6月組込み研修
l 3.1 2007年9月電気関係学会東海支部で発表(項目数評価:ETSS利用効果測定)
l 3.2 2007年11月組み込みLinux研修
l 4.0 2008年企業向け研修
l 4.1 2009年SPIN研修
l 4.2 2009年MISRA C++研修
l 4.3 2009年組込み研修
l 4.4 2009年情報処理学会,MISRA C1998,MISRA C2004のC90,C99との検討,吉川直邦氏
l 5.0 2011年 企業向け研修
l 6.0 2013年 OSC Nagoya2013
l 6.2 2014年2月CEST, MISRA=C:2012で楽しいCプログラミング
l 7.0 2015年2月セキュリティ・ESCR対応
l 7.1 2015年3月ソフトウェア科学会PPL2015
l 7.2 2015年5月 OSC Nagoya 2015
2018/05/19 (c)kaizen@wh.commufa.jp, @kaizen_nagoya