MISRA C++ワーキング・グループ 議長に聞くコーディング標準の活用法とコード・レビューのポイント

　2012年11月8日，全国町村会館（東京都千代田区）にて，MISRA C++ワーキング・グループの議長であり，MISRA Cワーキング・グループのメンバであるChris Tapp氏（英国LDRA社）が「コーディング・スタンダードとの付き合い方」と題した講演を行った（写真1）．講演の中で，2013年に策定を予定しているMISRA Cの次期バージョンや，MISRA C以外のコーディング標準の概要，コード・レビューの効率を上げるポイントなどについて解説した．

写真1　講演を行うMISRA C++ワーキング・グループ 議長のChris Tapp氏

●MISRA Cの次期バージョンはC99に対応

　MISRA Cとは，車載ソフトウェア開発に関する業界団体MISRA（The Motor Industry Software Reliability Association）が策定した，C言語によるコーディングのガイドラインである．1998年に最初のバージョン「Guidelines for the Use of the C Language in Vehicle Based Software」（通称「MISRA C:1998」）が策定された後，2004年に更新版（「Guidelines for the Use of the C Language in Critical Systems」，通称「MISRA C:2004」）が策定された．また2008年には，C++言語によるコーディングのガイドライン「Guidelines for the Use of the C++ Language in Critical Systems」（通称「MISRA C++」）も策定されている．

　これまでのMISRA Cは，1990年にISO規格となったC言語「ISO/IEC 9899:1990」（通称「C90」）に準拠することをルールとして定めており，1999年にISO規格「ISO/IEC 9899:1999」として改定されたC言語（通称「C99」．日本工業規格である「JIS X 3010:2003」がこれに該当する）には対応していなかった．そこで，C99に対応する必要があるとして，MISRAは2007年から，MISRA Cの次期バージョンの策定を開始していた．既に技術的な作業は完了しており，最終の編集作業に取り掛かっている段階．次期バージョンは2013年に公開する予定だという．

　次期バージョンは，C90への対応を維持しながら，C99に対応した項目を追加した．また，MISRA C:2004では一部制約が強すぎて実装しにくい面があったが，次期バージョンではその点を改善し，コーディングを容易にしながら望ましくない動作のみを未然に防げるように工夫しているという．また，ルール・チェックを自動化しやすいように，解析ツールで判定できるルールを増やした．そのほか，自動生成コードにルールを適用するための助言を盛り込んだという．

●各種コーディング標準に含まれるノウハウを吸収する

　システムに不具合を作り込むことを防ぐための標準は，いくつか存在する．これらを大別すると，プロセス指向の標準と，言語を限定した標準に分けられる．

　プロセス指向の標準としては，航空機業界におけるコード開発プロセスを定義した「DO-178B/C」や，機能安全規格「IEC 61508」（「ISO 26262」などの分野ごとのサブ規格を含む）などがある．

　また，言語を限定した標準としては，MISRAの「MISRA C」や「MISRA C++」のほか，米国Carnegie Mellon大学をベースにした調査グループCERTが策定した「CERT C」^注1と「CERT C++」，「CERT Java」がある．さらに，C言語規格を定義しているISO（International Organization for Standardization；国際標準化機構）のJTC1/SC22/WG14^注2が，C言語によるプログラムのぜい弱性を減らすために，ツールで検出可能なルール集を作成中である．現在，43のルールが挙がっており，次のISO C言語規格の付属文書として発行する予定であるという．

注1：一般社団法人 JPCERTコーディネーションセンターがCERT Cを日本語に翻訳し，下記のWebサイトで公開している．
http://www.jpcert.or.jp/sc-rules/

注2：JTC1は，ISOにおける，情報科学に関する技術委員会である．SC22とは，JTC1内のプログラミング言語に関する分科会であり，WG14は，その中のC言語に関するワーキング・グループである．

　このほか，日本で策定されたものとして，独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター（IPA/SEC）の「組込みソフトウェア開発向けコーディング作法ガイド（ESCR）」も存在する^注3．

注3：組込みソフトウェア開発向けコーディング作法ガイド（ESCR）の書籍は有償だが，PDF版は下記のWebサイトから自由にダウンロードできる．
http://sec.ipa.go.jp/publish/tn06-004.html

　これらのガイドラインは，より安全なシステムを開発するという目的は共通だが，細かいところでは違いがある．例えば，MISRAは言語が有する課題に焦点を当てているのに対し，CERTはセキュリティの課題に焦点を当てている．それぞれのシステム開発には何が必要なのかを考えて，これらのガイドラインを適切に組み合わせて使用するのが良いだろうという．ただし，複数のガイドラインを導入する場合には，矛盾が発生しないように注意する必要がある．

　Tapp氏によると，ソフトウェアの欠陥は二つに分けられる．一つは，演算子と単位を混同するなどの，プログラミング技術における欠陥（技術的欠陥）である．もう一つは，特定の状況においてアプリケーション・プログラムが意図したように機能しないなどの，アプリケーション上の欠陥である．技術的欠陥は静的解析でほとんど検出できるが，アプリケーション上の欠陥は，要件トレースなどによる動的解析や，要件をベースとした形式検証などによらないと検出できない．欠陥ゼロのソフトウェア開発を目指す場合，MISRAやCERT，ESCR，WG14などのルールは技術的欠陥を減らすのには役立つが，アプリケーション上の欠陥については，DO-178B/CやIEC 61508といったプロセス指向の標準によって取り組む必要があるという．