********************************************************************** セッションS3-d テーマ:自動車業界外の開発者のためのMISRA-C入門 講師:脇田 貴文 氏 (矢崎総業) 日時:2014/8/29 10:30〜12:00 参加人数:約25名(終了時) ********************************************************************** ・なぜ色々なガイドラインが必要なのかというモチベーションの部分を説明する ・入門レベルの内容とする ・自己紹介 - 主に、制御系ソフト系のR&Dを担当  - MISRA-C研究会に所属(2002年〜)  - 日本語解説書や欧州原案のレビューに従事。 ・セミナーの趣旨 - 安全のためのガイドラインを多くの開発者に興味を持ってもらいたい - MISRA-Cは、自動車業界を中心に運用され、10年以上にわたり保守されて きた安全なソフトウェアを開発するためのガイドライン。 - チェックツールが充実しているので自動車以外にも利用できる     ・最初に、いくつか質問 - 企業所属の人 or 大学所属の人? - 技術者、研究者 or 管理者? - 自動車業界? - すでにMISRA-Cを知っているか? ・質問について - 用語レベルの簡単な質問はその場で - 個々のルールやプログラムの話はメールで ・安全のためのガイドライン - 国際規格が多くなってきている - ガイドラインとは? 日本語で「行動規範?」なんとなく違和感 イメージとしては山頂にいたるための無数にあるラインの中で、ガイドさん が選ぶライン - C言語で何か機能を実装しようとすると、いろんな書き方がある - 無条件に、盲目に守るものではない。組み込みに関してはルールをすべて 守るのは不可能。 - 正しい理由、正しい手順であればルールを逸脱してもかまわない。 - 欧州はインフラを隣国とシェアをする必要があるので国際規格が必要 - 日本島国なので国際規格の必要性を感じない - 安全(人の命に関わる部分)は非競争分野であるべき 例えば、シートベルトとエアバックはどんな車にも標準装備 特許を公開している ・MISRA-Cガイドライン - C言語はFreedom! - たった一行なのに解読困難なプログラムもある こんなプログラムはだめだ なぜだめなのか それらを明文化したものが「C言語のコーディングガイドライン」 - MISRA-Cとは 安全なC言語のプログラムを書くために開発された欧州発のガイドライン 始まりは自動車向け 非競争分野 - エディタ 10人 - レビューア 52人(日本から8人) ・MISRA-Cのバージョン - 三つの版がある。初版は自動車向け。 - MISRA-C(1998) Guidelines For The Use Of The C Language In Vehicle Based Software 自動車用ソフトウェアにおけるC言語利用のガイドライン - MISRA-C:2004 Guidelines for the use of the C language in critical systems クリティカルシステムにおけるC言語利用のガイドライン - MISRA-C:2012 Guidelines for the use of the C language in critical systems クリティカルシステムにおけるC言語利用のガイドライン - クリティカルシステムとは たとえば、航空、宇宙、船舶、鉄道、プラント、医療機器、金融などの分野 - クリティカルシステム以外の分野、例えばおもちゃに内蔵されるような 検証にコストが掛けられないソフトウェアにMISRA-Cを適用すると、 コストの問題が出てくる ・MISRA-Cは価値のある技術文書  - 98年初版から継続的に保守がなされている。現在は第三版。  - レビュープロセスを経ているので正確な技術文書で、多くの専門家の知恵が 詰まった文書である - オープンなプロセスで開発されている - 作りっぱなしではなく掲示板でQ&Aができる仕組み ・MISRA-Cの勉強法 - 実際に140個のルールを勉強するには日本語解説書からスタート - JIS規格(ISO規格) C言語の入門書でチェックすることはやめて、規格でC言語の振る舞いを 理解することをすすめる開発組織の中で一冊は絶対に必要! - 練習方法が特殊なことが問題 - 自動車業界は未だにISO-Cの90年度版をベースに品質保証をしている。 かなり古い。 ・サブセット言語という概念 - 3文字表記 昔(ドイツ)の { } | がないキーボードがあったためにC言語には 3文字表記という機能がある - 3文字表記とは コンパイラが、特定の3文字の並びがソースファイル中に現れると、対応する 1文字に置き換える機能  - 偶発的に右表の3文字の並びが出現してしまうと危険である。 →3文字表記は、用いてはならない 用いているとチェックツールがエラーを吐いてくれる  - 使わない言語機能だからこそ明確なルールで禁止する! - 8進数 8進数というのは頭に0がついた数字 010は10進数で言うと、10ではなく8 switch文等でcaseを三桁で揃えたりして頭に0をつけると8進数と混同し、危険 1960年代は3bitの倍数のコンピュータを使っていたので8進数があった  - 今8進数は必要か? ほぼ必要ない 特殊な民族、UNIXのファイル属性の変更に使うくらい - MISRA-Cでは(0以外の)8進定数および8進拡張表記は、用いてはならない - 当たり前だし、使わないからこのルールはいらないじゃないか →使わないからこんなルールいらない、というわけではない   使わないからこそ禁止する!  - C言語∋ISO-C(3文字表記、8進数)∋MISRA-C(安全な言語)という関係 - 使わない言語機能(3文字表記、8進数)は偶発的な混乱をもたらすので ないほうがいい →必要最小限の言語機能にする - それがサブセット言語の考え方。  - Cの規格の中には、規格として未規定、未定義、処理系定義の項目がある →そういった部分を回避する - C言語規格で明確に定義されていないところは、同じCプログラムであっても、 コンパイラによって動作が異なるため回避すべき - 未定義の例:自動記憶域期間をもち、初期化されていないオブジェクトの値を、 代入する前に使用している場合 - MISRA-Cでの回避策:すべての自動変数は、用いる前に値を代入しなければ ならない - 強い型付け もともとのC言語よりも強い型付けを提供 C言語は、暗黙の型変換が発生する。知らないと危険。 - ISO規格の型システムにもう少し追加した強い型付けのシステムの提供 - MISRA-Cは、処理系の整数型に依存しないルールを目指している。 - ルールからの逸脱 「正当な理由」と「正当な逸脱プロセス」があればルールから逸脱してもよい  - 正当な理由の例 【参考】 JASO TP 14004 より R1: システムの性能 R2: サードパーティライブラリとの整合性 R3: 開発環境の制約 R4: 既存コードとの整合性 R5: バリエーション開発 R6: ハードウェアアクセス R7: 防衛的プログラミング R8: 適切な言語機能の使用 - 正当な逸脱プロセス ・文書化 ・レビュー ・承認 - 「必要ルール」と「推奨ルール」 必要ルールは正当な逸脱プロセスが必要 推奨ルールは必要なし - 必要ルールは逸脱の判断が明確 - 推奨ルールは逸脱の判断が曖昧 - MISRA-C : 2004 Rule 3.3 (推奨ルール)選定したコンパイラの整数除算 の実装について確認し、文書化し、十分に配慮すべきである -5÷3= -1あまり-2か -2あまり1か 整数除算は処理系依存 ・入門編まとめ - MISRA-Cとは安全のための技術で、非競争分野 - C言語にはガイドラインが必要 - サブセット言語という概念の安全性 - 個別に勉強するなら、MISRA-C研究会の日本語解説書で 実際にコンピュータを動かしてサンプルをコンパイルしながら勉強した方が いいだろう ・MISRA-C2012について - 日本語の解説書を準備中 - 一番大きな変更点:C99に対応した C90とは1990年版のISO-C規格のこと C99とは1999年版のISO-C規格のこと つまり、新しいC言語のバージョンに対応した! - MISRA-C:2012のジレンマ C99∋C90 C99はC90に対して後方互換性がある。C90はC99のほぼサブセット サブセット言語のほうが安全であるならC90のほうが安全? C99は言語機能が多い。だからこそガイドラインは重要 安易にC99移行しないほうがいいかもしれない(どちらを使うべきか検討中) - MISRA-C:2004か2012か 保守的な選択 安全を重視するのであれば MISRA-C2004とC90の組み合わせ→自動車など 合理的な選択 品質を保ちつつ実用的にしたいなら MISRA-C2012とC90の組み合わせ→自動車業界外 ・MISRA-C:2012日本特有の問題 - C99では変数名に日本語(拡張文字)が許されてしまうコンパイラが認めら れている - 例:int あ; - 欧州にとってはどうでもいいので議論されていない - 翻訳限界 - MISRA-C:2004 ルール 5.1 (内部及び外部) 識別子は、31文字を超える特徴 に依存してはならない - 関数名があまりに長い(翻訳限界を超えている)と、末尾のアルファベット を認識してくれない(31文字まで) - では、「あ」は何文字に相当するか? 結論:わからない 最悪の場合「が」が20文字に相当する 結局はコンパイラ依存で、何文字になるかわからない  - 独自の社内ルールとして拡張文字を使わないようにすればいいのでは? 識別子に拡張文字および国際文字名を使用してはならないというルールを 追加するべき  - 日本語(拡張文字)の変数名のほうがわかりやすい場合があるかもしれない →議論の余地あり ・MISRA-C2012のうれしさ  - 1番うれしいのは、技術文書としての価値が高くなったこと ルールの数は2004とあまり変わらないのに厚さが2倍。 →ルール解説が充実し、サンプルプログラムも増えた。 英語圏では2012のほうがわかりやすいのでは - 2004(第二版) → 2012(第三版) の変更点について ルールの違いはそんなに大きなものではない ルールが緩くなった部分が多い。 以前よりハードルが下がっている - 正常進化の例 ① 2004ではgoto文の使用が全面禁止であった 2012では推奨ルールに格下げされた さらに goto文は、同一関数内の後方に宣言されるラベルにジャンプしなければなら ない。というルールが追加された ② 代入されているのに使用されない変数の使用が明示的に禁止された ※代入には副作用が発生する 2004必要ルール 空文でない場合には、次のいずれかの条件を満たさなければならない。 a) 実行方法にかかわらず、1つ以上の副作用があること。 b) 制御フローを変更すること。 副作用:システムの状態を書き換えてしまうような振る舞い IOポートでは値を代入するだけでなく、参照するだけでも副作用が発生する 2012必要ルール デッドコードは、存在してはならない。 デッドコード:実行されているが除去されてもプログラムの動作に影響を 与えない演算。 ③ one entry one exitの原則に関するルールの変遷 1998推奨ルール 関数は1つの出口しか持ってはならない。 2004必要ルール 関数では、関数の最後に唯一の出口がなくてはならない。 2012推奨ルール 関数では、関数の最後に唯一の出口があるべきである。 組込みシステムは異常系の例外処理(エラーのハンドリング)が多くなる 傾向がある。 引数チェックの結果がエラーとなるような場合は、即returnできるように なった。  - 結論 大きな方針の変化はないが細かな調整が入っている ・MISRA-C研究会と日本語解説書  - MISRA-C研究会は、主に自動車部品、開発環境ベンダの集まり MISRA-Cの解釈について議論 日本語版(翻訳レビュー) 日本語解説書(執筆) セミナーなど - 欧州発のガイドラインについて、日本語訳と日本語解説書がないと日本の 業界は対応できないことに問題意識を持っている - 現在 MISRA-C:2012の翻訳版についてのレビュー作業中 MISRA-C:2012の日本語解説書について作業中 来年くらいには2012の日本語解説書が公開できるのでは - 現在はメンバーの募集はしていないが、MISRA-C次回改訂の際は新たに メンバーを募集世代交代しながら継続させていく必要がある - こういった活動に興味がある方はぜひ教えてくだい ・最後に  - 業界のルールを守っているだけだと平凡な開発になってしまう 業界のルールを守るだけではダメ - 逸脱することが最善かもしれない 個々のルールを深く理解しなければ逸脱しても安全かどうかの判断ができない 盲目的にルールを守るのではなく背景の理解が必要 - 特に自動車以外の開発者は、全てのルールを盲目的に守る必要などない。 今日は C言語ガイドラインの必要性 サブセット言語(言語の機能を狭める)という概念 がわかればOK 個々のルールの理解を座学で勉強するのは難しい。 実際に動かしてみて学ぶのが一番よい。 【拡散希望】 MISRA-Cは安全のためのガイドラインなので、自動車業界以外にも、多くの ところで使ってほしい 質疑応答 Q1、正常進化の例②に関してデッドコードの詳しい定義は? A1、この質問は個別にメールで Q2、MISRA-Cに関する質問はどこに問い合わせたらいいのか? A2、MISRA-C研究会と一緒に解決していきましょう Q3、必要ルール、推奨ルールの区別はMISRA-Cの中にはっきりと定義されているのか A3、MISRA-Cの文章の中で定義されています Q4、その他の言語でガイドラインはあるのか? A4、C++に関しては若干存在する   たとえば、IPAのC++, MISRA-C++, JSF++ など   C言語にはISO規格、JIS規格があるので安全性を議論できる   国際規格があるかどうかが重要 以上