S5a イントロ昨年は脇田さん、一昨年は二上さんがMISRA-Cの内容を中心に解説をした。今年は趣向を変えて、MISRA-C研究会の活動を中心に紹介していく。注：後述するように構成が変更されたため、規約については「ガイドライン」と呼称するのが適切であるが、　　日本語での呼びやすさや以前の慣例からここでは「ルール」と呼称する。 1.Introduction 1-1　目的 MISRA-C研究会はSSESAMEのWG3である。研究会の成果物である「MISRA-C解説書」がどんなものであるか、を何となく掴んで帰って頂きたい。 1-2　前提初級者対象ではあるがC言語の経験が全くない人には辛い。 1-3　書籍これまでのMISRA-C研究会の成果を紹介する。・組込み開発者におくるMISRA-C 組込みプログラミングの高信頼化ガイド・組込み開発者におくるMISRA-C 2004 C言語利用の高信頼化ガイド日本国内では「MISRA-C研究会の解説書 = MISRA-C」と認識されていることが多く、現場のエンジニアがMISRA-Cの原書を読むことはまずないと思っている。これらを確認するため、会場にいる皆さんの中で、MISRA-C:2012の原書を持っている人がいるか聞いてみたい。会場反応なし。やはり、MISRA-Cの原書を持っている人はいないとわかった。 1-4　自己紹介デンソー勤務。エレクトロニクス分野内で11回の異動を経験。ソフトウェアにかぎらず、様々な業務の経験がある。チャンスに向けて準備を怠らなければ、道は必ず開ける！ 2.　MISRA-Cとは？ 2-1　MISRA-Cの概要図1枚でMISRA-Cを表現する。 MISRA-CはC言語規格の中に存在していると言っていい。必要ルールは原文では"Shall"と記述され、約束として必ず守らなくてはいけないルールである。同様に推奨ルールは"should"と記述され、努力目標的な意味があるルールである。 "推奨"と"必要"で内容に重複や食い違いが見られる部分があるがこの辺りがMISRA-Cを読む上のポイントであり、以降で詳細に解説する。参1.　MISRA-Cルール間の関係 gotoを使っても、推奨ルールに準拠できないだけで逸脱処理は必要ない。ただし、下から上へのジャンプが発生する場合は、必要ルールに準拠できないので、逸脱処理が必要。逸脱処理とは、ガイドラインを守れなかったときに、その妥当性や安全性について文書化することである。 2-2　MISRA-Cの歴史 MISRA-Cの歴史を解説する。 MISRA-C:1998は、車載ソフトウェア向けに作成された MISRA-C:2004は、車載SW以外にも有効であると考え、対象をクリティカルシステム向けに拡大した。 MISRA-C:2012は、対象はクリティカルシステム向けを維持した。新たに準拠が強制されるmandatory（必須）ルールが新設。詳細は後述する。ルール数は増えているが、新版で削除になった旧版のルールもあり、純増ではない。 2-3　MISRA-Cの活用意義 (1)自動車メーカ　部品の受入れ基準として利用。準拠度合や逸脱処理の妥当性などを確認する。 (2)自動車部品メーカ/ソフトウェアベンダ　ソフトウェアの品質確保のため、コーディングルールとして利用。 (3)静的解析ツールベンダ　解析ツールの開発のため、適合を確認するための規格として利用。 (4)ソフトウェア開発者/学生　安全で可読性の高いC言語を記述するための教材として利用。 2-4　MISRA-Cの活用方法 MISRA-C研究会でオススメする活用方法は、 MISRA-Cの思想や背景を理解した上で、修正の必要性を吟味して安全性の確認を行ったうえで、逸脱処理を行うことである。参2.　MISRA-C対応フロー表示したフローはMISRA-Cの必要とするプロセスに合致している。しかし、「直す気があるか」などとおざなりな理由で修正の可否を判断してはいけない。「直す気がない」なら安易でない、確固たる理由を持った逸脱処理が必要。 3.　MISRA-C:2012について (1)全体がRuleとDirectiveに区分され、構成が変更になった。　逸脱が許されない必須ルールが追加された。 (2)ルールが一文のみでなく、補足と例外を含んだ形に変更された。 (3)静的解析ツールの活用を前提とした決定可能性や解析範囲が明示された。 (4)C99対応となった。 3-1　MISRA-C:2012の特徴１・Directive 　2004までにあったはっきりしないルールをまとめたもので、　多くはソースコードのみでは判断できないものである。・Mandatory 　MISRA-C:2012に適合を主張するには、逸脱処理が許されない新設されたルール。 3-2　MISRA-C:2012の特徴２ 2012はルール本文のみで理解できないルールが増えたため、その詳細を知るためには補足を読む必要がある。 "例外"として、ルールの本文から捉えると違反となるような記述でも、ある特定の場合にルールに準拠したとみなす場合が解説されている。 3-3　MISRA-C:2012の特徴３以前のバージョンと比較して、ツールに配慮したルールが増えた。ツールによる違反の特定が容易になっている。 4.　MISRA-C研究会とは？これまで3回の活動があった。今回の活動は名古屋市工業研究所の小川さんを中心に行っている。成果物としての解説書の発行が間近になっており、活動は収束期に入っている。 4-1　MISRA-C研究会第１期活動自動車技術会の翻訳を支援。日本規格協会の協力を得て、ルールの意図を理解する活動を纏めた解説書を出版。 4-2　MISRA-C研究会第２期活動英国に出張し、MISRAに直接ドラフト版の修正を提案。前解説書の経験を活かし、より充実した解説書を出版 4-3　MISRA-C研究会第３期活動研究会の一部メンバはドラフト版のレビュを行い、日本の技術者の立場から不適切なルールに対して修正を働きかけ、日本の開発環境に馴染まないルールを廃止した。過去の解説書を凌ぐため、更なる改善努力を行い、電子書籍での発行に初挑戦。 5　MISRA-C解説書ができるまで研究会の最大の成果物は「MISRA-C解説書」である。研究会で議論した内容について、コードの事例を交えて紹介する。コード事例1 このコードの問題とは==と=の書き間違いであり、 MISRA-Cではこれらを2つのルールによって静的解析ツールで検出することが可能である。このように、プログラマのミスをツールで検出できることが、MISRA-Cの採用によるメリットとして言える。コード事例2 C言語では、式の評価順序はより多くの処理系に対応することを前提としているため、基準がない。未定義とは決まっていないことであり、この結果が100とするコンパイラでも正しいコンパイラとなる。コード事例3 switch文の節に誤記があったとしても、文法上はラベルとして扱われるため、コンパイルエラーにはならない。 MISRA-Cに適合した静的解析ツールを利用することで、このようなプログラマの些細でかつ重大な間違いを発見できる。コード事例4 例示した式はマイコン、正確にはレジスタサイズが変わると結果が変わる。これは、C言語における汎整数拡張という機能の影響であるが、このリスクもMISRA-Cに準拠した記述を行えば回避することができる。 5-1　研究会メンバー紹介会場にいた研究会メンバが直接自己紹介を行った。矢崎総業　　脇田さんサニー技研　尾仲さんヴィッツ　　森川さんアイシン・コムクルーズ　後藤が登壇し、挨拶した。メンバ紹介の目的は、MISRA-C、C言語に困った時にこのメンバを思い出して、コンタクトしてもらって、解決に役立てて欲しいからである。エピソード【池田】米駐在中に部下にMISRA-Cに関する100問のテストを行ったが、いわゆる"デキる"技術者は点数が良く、そうでない技術者は点数が低かった。すなわち、"デキる"技術者が普通にやっていることがルールになっている。 5-2　解説書作成のプロセス MISRA-C:2004が普及していると判断し、2012と2004の差分を意識して解説した。特に2004では「潜在的問題」としていた項目を「ねらい」に変更し、そのルールが抑止する本当のリスクを記述した。研究会の現在の状態は、最終の会議が終了し、電子書籍発行に向け校正を実施している状態である。電子書籍の発行を目指している理由は、主に以下のようなものである。・改訂が容易・単語検索が容易・書籍より軽い 5-3　解説書の読み方「解説書」では、技術的解説のみならず、やや深い話題にも触れている。その多くは、研究会メンバーのエンジニアとしての思いを伝えるため、コラムとして記載される予定である本文自体の説明にとどまらず、C言語規格の説明も折込み、適合/非適合の理由や、非適合の場合の影響についても記載した。最後に。 MISRA-C研究会はSWEST実行委員会と似たようなボランタリーな活動なので、SWESTで是非講演したかった。講演できたことを光栄に思う。