MISRAとSECのコーティングガイドライン 講師：宇野 結（松下電器） コーディネーター：小川 清(名古屋市工業研究所) 2006/07/14 チュートリアル2 S2-3-3 C会場：13:20-15:00 参加者：30名（開始時） ◇修正案◇ ◎背景 ○開発工程と品質の作りこみ コーディング規約は，実装技術に関してフォーカスしている ○MISRAの取り組み 自動車の安全性に関連する電子システムなどの組込みシステム開発における最善 の方法を提案 ○IPA SECの取り組み IPA SECでは，組込みソフトウエアの品質に関して，実装技術にフォーカスして いる ○自動車産業におけるC言語の利用状況 C言語の利点 ・多くのマイクロプロセッサのハードウエアをサポート ・他の高級言語よりもサイズが小さく，RAM容量が少ないコードを出力可能 ・ツールが充実 ○組込み産業の実態とC言語利用の実態 使用されているプログラミング言語 ・C言語：63.5％ ・c++：16.9% ・アセンブラ：13.9％ 現状では，C言語が多いのが実態である ○MISRA-Cの課題認識とアプローチ Cの危険性 ・==と=のタイプミス（文法的には正しい） ・演算子の優先順位 ・仕様があいまい．コンパイラによって動作が異なる ・コンパイラがバグを含む可能性がある． ・0による除算，実行時エラーに対してはプログラマが責任をもつ必要がある 上記の危険を回避できるC言語のサブセットを定義する！ ”MISRA C言語” ○IPA SECの課題認識とアプローチ 品質確保のために守るべきはずの，コーディング規約が守られていないのはなぜ？ ・ルールの必要性が不明確 ・ルール違反への対応が不明確 ・不適切なルール ・そもそもルールが多い ・適切なツールの不足 IPA SECの取り組みとして， 品質の視点から規約の基本概念を”作法”として整理しよう ◎MISRA-Cと作法ガイド ○MISRA-Cの特徴 ルールの形でC言語のサブセットをサポート ・意味を一意に解釈できる文法的に正確な記述 ・スタイルは規定しない ・スタイルガイドの遵守は，範囲に含めない MISRA−Cに準拠していることを主張できる ・ルール準拠が強制されていることを示す合致マトリクス どのツールがどのエラー出力を担当するかを表にまとめる ・すべてのCコードが次のいずれか ルールに準拠 ルールからの逸脱であるが，文書化されている ・遵守されていないルールのリストが維持管理されている などの証拠となる文書によって主張できる ○コーディング作法ガイドの特徴 作法やルールを体系化 ・品質特性に基づいて分類 信頼性，保守性，移植性，効率性 保守性に分類される作業としてスタイルにも言及 プログラムの誤りに関する項目 ・MISRA-C，Indian Hill，GNUなどを参照した． ※本には，MISRA-Cのみ対応関係を明示 ・作法に基づくCコーディング規約の作成を支援 すぐにつかえる具体的なリファレンスルールを提示 ルールの必要性を例を示して解説 ルールの採用・不採用を検討する際の選択指針を提示 ○MISRA-Cの構成（MISRA-C:2004） ・C言語の利用と問題点 ・MISRA-C ・ルールの紹介 ・ルール 141ルール（MISRA-C:1998は127） ○コーディング作法ガイドの構成 Part1：コーディングガイドの読み方 Part2：作法表 信頼性について 保守性について 移植性について 効率性について Part3：組込みソフトウエアにありがちなコーディングミス （129ルール） ○品質概念・作法・ルール コーディング作法ガイドの構成を図で説明 作法・ルールを参考にしてプロジェクト独自の規約を作成 ○作法ガイドの作法例 信頼性 作法概要：領域は初期化し，大きさに気をつけて使用する 詳細：領域は，初期化してから使用する ルール：自動変数は宣言時に初期化する ○作業ガイドにおけるMISRA-Cの扱い MISRA-Cルールを引用している場合には対応を明示 ・ルール14.5を例に解説 作法ガイドのなかでMISRAのルールを引用して比較している ○プログラマによるエラーの扱い 例）=と==のタイプミス ・MISRA-C ルール13.1（required） ルールを定めて，=の記述を禁止することでタイプミスを回避 ・SEC Part3ありがちなコーディングミスで取り上げる 「タイプミスがありそうだから気をつけろ」という注意を促す 「守るべきルール」という位置付けとは区別している！ ○プログラマが誤解しやすい文法 例）誤解されやすい演算子の優先順位 ・MISRA-C ルール12.5 ルールを定めて括弧の記述を義務付けることによって誤解によるミスを回避 ・SEC 保守性1.4 <<演算子の優先順位が分かりやすいように記述する>> ※<<と>>で囲まれたものは文書化ルール．独自にルールを定めよという意味 M1.4.2 演算の優先順位を明示するための括弧のつけ方を規定する 必要に応じて，プロジェクトごとに具体的なルールを規定する 文章化ルール：優先順位を表す括弧のつけ方をプロジェクトで規定！ ○コンパイラのバグ 例）関数形式マクロの実引数の数の誤り ・MISRA-Cルール 19.8(required) ルールを定めて禁止することによって，プリプロセッサの不十分さを補完 ・SEC Part3に記述 6 コンパイラによってエラーにならないケースがある記述 同様の問題について言及しているが，「守るべき」ルールとは区別 ○実行時のエラー回避 例）0による除算など ・MISRA-C ルール21.1（required） Cのサブセットにはならないが，ルールとして規定 ・SEC 信頼性 3.5実行時にエラーになる可能性のある演算に対しては，エラーケ ースを迂回させる R3.2.1 除算や乗除算の右辺式は0でないことを確認してから演算を行う ルールとして規定 ○ルールの厳密性 例）シフト演算子の右辺の項の値の範囲 ・MISRA-C ルール12.8(required) ルールを厳密に規定するために「underlying type」という用度を定義して記述 ※MISRA-Cの特徴であり，同時に難しくしている表現 ・SEC 信頼性2.5 情報損失の危険の可能性のある演算は使用しない R2.5.4 シフト演算子の右辺の項はゼロ以上，左辺の項のビット幅未満でなけ ればならない 解説・・・左辺（シフトされる値）がint型より小さいサイズの型の場合に， シフト数としてintのビット幅までの値を指定することは，意図がわかりにくい intのビット幅以下の値をシフトする場合の注意点について解説で言及 ○ルール選択の指針 例1 例）自動変数の初期化 ・MISRA-C ルール9．1 値が代入されずに使われている自動変数が存在する場合には「MISRAーC」準拠 といえない ・SEC 信頼性1．1 値が代入されずに使われている自動変数成の危険性を作法として，周知徹底さ せる程度にとどめる ○ルール選択の指針 例2 例）引数をもたない関数の宣言 ・MISRA-C ルール16.5 仮引数をまたない関数の仮引数をvoidで宣言しない記述が存在する場合は 準拠ではない ・信頼性2.8 R2.8.1宣言，仕様，定義に矛盾がないことをコンパイラが判断でき る記述とする 選択指針○：守らないと品質特性を損なうと考える このような記述が存在すると著しく品質特性を損なうのでルールとして選択する ○ルールの選択指針 例3 例）演算子の優先順位 この場合，MISRAとSECでの扱いは同じ ○スタイルへの言及 ・MISRA-C 言及していない ・SEC 保守性 4統一した書き方にする 各作法のなかで，プロジェクトで定めるべき文書化ルールとして記述されている スタイルとして規定する項目を例示 コーディングスタイルを統一する コメントの書き方を統一する 名前の付け方を統一する ファイル内の記述内容と記述順序を統一する 宣言の書き方を統一する ナルポインタの書き方を統一する 前処理指令の書き方を統一する ○まとめ MISRA-Cとコーディング作法ガイドの比較 ・MISRA-C 品質を確保するためのCのサブセットを規定 準拠していることを主張することに意味がある ・SECコーティング作法ガイド コーディングのシーンで守るべき作法を，品質の視点を考慮して整理 コーディング規約の作成を支援 プログラマやレビューをする人への教育的な視点も含む 課題への視点 アプローチは異なるが，最終目標「Cソースコードの品質確保」は同じ （説明は，以上） ○質問1 SESSAMEのワーキンググループ3では，ルールの意図，理由が書かれている．SECの 取り組みと似ているのではないか？ 答え SESAMMEでは，MISRAではルールの理由の説明が（開発者に対して）十分ではないと 考えている ルールを守らなければならない理由に関して，基本的に両者に違いはない． MISRAは，準拠と非準拠を明確に判断可能にしている SEC は，作法を整理して解説することに重点を置いており， 準拠，非準拠に言及していない ○質問2 MISRAとSECコーティングガイド似ているのであれば，どのように使い分けすれば 良いのか？ 自動車はMISRAだろう． 他の業界では，どちらを採用すべきだろうか？ 答え 難しい質問である SEC には，現在コーディング規約を導入できていない現場に対して コーディング規約の導入を容易にしたいという思いがある． いきなりMISRAを全部導入するのは大変である． 導入としてSECの白丸部分を採用していくのが現実的だろう． ○質問3 自動車業界におけるMISRA-Cの準拠度合いはどの程度か？ 答え 多いと思う． 松下電器でも，自動車関係の部署で MISRA-C を守っているところがある． 準拠していることをどのように主張するかが難しい 警告がないことだけではなく， 逸脱をしっかりと管理していることまで含めて準拠を主張できる． ○質問4 弊社ではインターネット関連製品を作っている 組織として，スタイルを含めた規約を決めて運用するのが大事という解釈でよい か？ 答え （SEC の作法ガイドの主旨からするとそのとおりである） MISRA に関して言えばスタイルについては言及していない． MISRA としてスタイルを決めて統一することは非常に困難． ひとつのソフトウェアを開発する場合でも困難な場合がある． 例えば複数のプロジェクトでコードを書いているような場合． そこで，文法のみを優先して規定し，スタイルについては言及していない． MISRAはイディオムも禁止．白黒はっきりつけたい（K&R本を例に）． SECは，イディオムを禁止するメリットを見出していない ○質問5 自動車業界からの質問． MISRA-Cは出来る範囲でツールで検証することができる． 一方，SECコーディング作法ガイドでは，ツールで検証できないルールが含まれている． 現場で検証をすることを考えると，ツールを使うか，レビューでやるかを判断す る必要がある 現実的に，全部をレビューでやるのは無理だろう． SECでは，ツールで検証することを想定しているのか？ 答え 作法ガイドの議論では，全部ツールでとれるものを羅列するのは止めようという 意見があった． プログラマに対して，常に意識して欲しいルールを定めることも必要だろう． ツールのためのルールではなく，コードを書く側のルールを決めたい． 質問続き 現場では，自動化をすすめたい． なので，プログラムの検証も出来る限りツールでやりたい． 現実として，ある種のコーディングスタイルもツールで検証している部分もある． 以下を要望したい． もう少し，ルールの成立理由がまだ明確になっていない部分もある． ツールでの検証容易性もガイドに書いて欲しい． コーディングルールの位置付け：誰が書いても同じコードになるようにしたい． 答え ツールに関する指摘に関してはその通り． 今度の参考にしたい． ○質問6 C++に関して，MISRAとSECの取り組みは？ 答え MISRAは始まっている SECはまだ始まっていない 二上氏のコメント C++に関してはWGを立ち上げた程度． 4，5年掛かるだろう． 組込みはスタティックなインスタンス生成が多い． ダイナミックなインスタンスの生成の扱いが課題． テンプレートの扱いはどうするかは難しい． ○質問7 MISRA-C準拠のソフトウエアに対して，さらにSECコーディング規約ガイドの中で やるべきことはあるか？ 答え 今ここで思いつくのは， マジックナンバーを使わない NULLポインタの記述方法（0 か NULL か）を決める など． SECはMISRAよりも導入段階に利用できる作法である コーディング規約を導入していない現場に，手始めとして導入してほしい． ○質問8 弊社では，コーティングによる不具合は，製品の不具合全体から考えると少ない． それでも必要なのか？ 答え コーディングによる不具合の割合については，日経エレクトロニクスの記事に 某自動車メーカでで10%という記事があった． 割合は少ないかも知れないが，コーティング規約を導入することで， 確実に不具合が減らせるので，やはりやるべきだろうと思う． ◎参考文献 SEC BOOKS 組込みソフトウエア開発向け コーディング作法ガイド[C言語版] 翔泳社 以上．