ＥＴ ＷＥＳＴ２０１４ 併催 Ｉ ＰＡセミナー 組込みソフトウェア開発向け コーディング作法ガイド（ESCR）[C 言語版] 改訂内容のご紹介 独立行政法人 情報処理推進機構 ソフトウェア高信頼化センター コーディング作法ガイド改訂ＷＧ 2014 年 7月 30 日 日本電気株式会社 ソフトウェア生産革新本部 三橋 二彩子 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 1 目次 １．コーディング作法ガイドの概略 ２．改定の背景・目的 ３．改定内容 ４．今後の予定 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 2 1. コーディング作法ガイドの概略 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 3 コーディング作法ガイドとは 組込みシステムの信頼性向上をミッションとして、2004年に 開始された IPA/SEC 活動の成果物として作成 目的 ：実用的なコーディング規約の策定・運用の促進 対象言語 ：C言語、C++言語 対象読者 ：規約の作成者、プログラマー、レビューアー 作成当時の問題意識：組込みソフトウェアの開発が拡大する中、上流の 問題は大きいが、下流の問題も見過ごせない ソフトウェア開発の最終成果物はソースコードであり、その品質確保は 基礎体力といえる ソースコードの品質確保には、ソースコードの標準化が有効 一方で、コーディング規約の策定には時間がかかり、また、形骸化する ことも多い Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 4 （参考）策定当時の開発規程や開発標準の整備状況 2004年版 組込みソフトウェア産業実態調査報告書 欧州 はい いいえ 日本 より 米国 要求仕様書や設計仕様書 に関する規定がある 品質管理規定がある 製品の保証や不具合に伴う損害 などを処理する品質保証がある ISO基準（ISO／IEC9000） に準拠している コーディング規定がある 品質管理を支援するツール （工程管理、構成管理など） を導入している CMMに準拠した管理プロセス を導入している シックスシグマに準拠している 0% 20% 40% 60% 80%100% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100% Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 5 （参考）ソフトウェア開発における不具合の分布 ソフトウェア開発における不具合の分布 ソフトウェアの不具合の 1/3 はソフトウェア実装工程で作り込まれている ソフトウェア不具合発生工程別件数比率と発見工程の内訳 発見工程の内訳 発 生 工 程 ソフトウェア 実装・デバッグ ソフトウェア テスト システム テスト 2011年度版組込みソフトウェア産業実態調査 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 6 (参考）コーディングにおける問題点の例 プログラミング言語の基本的な使い方を理解しただけでは実 際のソフトウェア開発に対応しきれない ・ Ｃ言語は記述の自由度が高く技術者の経験の差が出やすい言語のため、 記述方法に対する標準化が必要である ・ 新人研修などをとおしてコーディングの基本を徹底して学習することが 必要 記述ミス例 #define M_STOP 正しい記述 0x01 ・ ・ ・ if （motorStatus & M_STOP != 0）｛ motorStatus &= ~M_STOP; Copyright © 2014 IPA, All Rights Reserved #define M_STOP 0x01 ・ ・ ・ if （ （motorStatus & M_STOP） != 0）｛ motorStatus &= ~M_STOP; Software Reliability Enhancement Center 7 沿革 2004年 10月 2006年 6月 2007年 7月 コーディング作法ＷＧ活動開始 コーディング作法ガイド Ｃ言語版 V1.0 出版 同上 V1.1 出版 2008年 4月 2010年 11月 Ｃ++言語対応へ活動開始 Ｃ++言語版（ESCR Ｃ++） V1.0 出版 2011年 4月 JIS規格化 （JIS X0180 「組込みソフトウェア向け コーディング規約の作成方法」） 2013年 5月 2014年 3月 Ｃ言語版 V2.0 作成開始 同上 V2.0 出版 （参考） ESCR Ｃ言語版 V1.1 利用状況 組込み系ユーザでは、４割が導入済みもしくは検討中 品質と生産性の向上に有用との評価 2012年度「ソフトウェア産業の実態把握に関する調査」 書籍およびPDFのダウンロード 3万冊 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 8 作法ガイドの特徴 品質特性により、ルールをトップダウンに体系化 品質特性 > 作法（概要・詳細） > ルール 品質面からの段階的詳細化で、ルールの意義の理解促進 すぐに使えるルールのリファレンス MISRA-C、GNU、参加企業のコーディングルールなど 世の中の多くのコーディングルールを作法に対応して提示 ルールの特性を提示 対応する品質特性を保つために重要なルール、など 初級者にもわかり易い表現 厳密さよりもわかり易さを優先 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 9 作法ガイドの構成 Part1 コーディング作法ガイドの読み方 1. 概要 2. ソースコード品質のとらえ方 3. 本ガイドの利用方法 Part2 作法表 [信頼性] R1 領域は初期化し、大きさに気 をつけて使用する R2 データは範囲、大きさ、内部 表現に気をつけて使用する R3 動作が保証された書き方にする [保守性] M1 他人が読むことを意識する Copyright © 2014 IPA, All Rights Reserved M2 修正誤りのないような書き方 にする M3 プログラムはシンプルに書く M4 統一した書き方にする M5 試験しやすい書き方にする [移植性] P1 コンパイラに依存しない書き 方にする P2 移植性に問題のあるコードは 局所化する [効率性] E1 資源や時間の効率を考慮した 書き方にする Part3 組込みソフトウェアにありがちな コーディングミス Software Reliability Enhancement Center 10 品質特性と作法、ルール 作法 ルール ：品質保つための慣習、実装の考え方。言語独立 ：守るべき具体的な決めごと 品質特性で 整理された 作法 ルールは 参考として 提示 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 11 作法、ルールの構成 世の中の作法とルールを広く集めて整理 ライブラリ関係、メトリクス関係は対象外 コーディングミスは、別途整理 SEC コーディング作法 インプット 既存のルール ・MISRA-C ・Indian Hills ・GNU ・Linux Kernel Coding Standard ・C style Guide etc ライブラリ・メトリクス関係 は含まない。また、コー ディングミスは別途整理 品質特性で 整理 説明追加 部会メンバ企業のルール ドメイン特有のルールなど Copyright © 2014 IPA, All Rights Reserved 既存のルール Software Reliability Enhancement Center 12 ルールの表現例 信頼性 1 領域は初期化し、 大きさに気を付けて使用する。 コード例 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 13 本ガイドの利用方法 – コーディング規約の作成 Part 1で、コーディング規約の作成方法などガイドの利用方法を説明 ○ コーディング規約は、プログラム設計に入る前を作成する コーディング規約作成 方針の決定 ESCR 例えば、品質特性を考慮する ・ フェールセーフを重視 ・ メンテナンス性を考慮 など … コーディングルールの選択 選択指針 （マークなし/●/○） を参考 にルールを選択する ルールのプロジェクト依存 部分を定義 ルール適用除外の 手順を決定 Copyright © 2014 IPA, All Rights Reserved 規約化 （選/規/文） に従ってルールを 確定する • 「選」のルールは、いくつかのルールの選択 肢が示されているので選択する • 「規」、「文」のルールは、プロジェクトで ルール規定が必要。詳細を確定する Software Reliability Enhancement Center 14 2. 改定の背景・目的 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 15 今回の改定における課題と目的 課題 ESCR は C 言語規格の旧版である 通称 C90 に準拠しており、 新しい規格 C99 に対応する必要がある（MISRA Cも今回 C99 に対応） MISRA C が大幅改訂を実施したことで ESCR の記述とのリン クがとれなくなった 目的 準拠する C 言語規格を C90 から C99 に更新し、新たな機能で のコーディングを容易にしつつ、組込みソフトウェアを高信頼 に作るため望ましくない動作が防げるようにする 相互に引用を行っており、ESCR が参照している両者共通的な 部分で MISRA C の改訂に対応して記述の齟齬がないようにす る Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 16 改訂の成果 準拠する C 言語規格の C90 から C99 への拡大・更新 新規となる項目の反映の有無を確認 MISRA C: 2012 との対応関係の更新 ESCR が MISRA C:2004 を参照している25箇所について、対応 関係の見直し 新規となる項目の反映の有無を確認 ⇒ ESCR［Ｃ言語版］ V2.0 日本語版の出版 改訂版の英訳 ⇒ ESCR ［Ｃ言語版］ V2.0 英訳版 PDF Copyright © 2014 IPA, All Rights Reserved 2014年3月 2014年7月 Software Reliability Enhancement Center 17 （参考） 改訂委員会メンバー 名 主査 前 所 属 三橋 二彩子 日本電気株式会社 伊藤 雅子 富士通株式会社 宿口 雅弘 イーソル株式会社 舘 伸幸 国立大学法人 名古屋大学 十山 圭介 独立行政法人情報処理推進機構 西山 博泰 株式会社日立製作所 二上 貴夫 株式会社東陽テクニカ Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 18 3. 改定内容 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 19 主な改定項目 主な改定項目は、以下の通り (1) JIS X 25010(JIS X0129-1の後継規格)への対応 (2) C99への対応 (3) MISRA C 2012 への対応 (4) その他の改善・改訂 ※ 修正ルールの一覧は付録に示す Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 20 (1) JIS X 25010 への対応 ESCRが利用している品質特性の定義 JIS X0129 が、 JIS X 25010:2013によって置き換えられた 変更点は、品質特性、副特性の追加・削除、名前の変更など ESCRでは「表 ソフトウェアの品質とコードの品質」をJIS X 25010:2013 に対応。追加された品質特性「セキュリティ」 に対応するコードの品質の説明を追加（次ページ参照） 一方で、品質特性「セキュリティ」に関連するコーディング 作法は「CERT C セキュアコーディングスタンダード」に委 ねると記述 ※ CERT C セキュアコーディングスタンダード http://www.jpcert.or.jp/sc-rules/ Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 21 「表 ソフトウェアの品質とコードの品質」の修正 品質特性の追加に対応して、コードの品質の定義を追加 橙色字部分追加 品質 特性 品質副特性 成熟性 信 頼 性 可用性 コードの品質 使い込んだときのバグの少なさ。 (略) 使用することを要求されたとき、システム、製 【追加】 品又は構成要素が運用操作可能及びアクセス可 能な度合。 障害許容性 (略) 回復性 (略) バグやインターフェース違反など に対する許容性。 【追加】 一つの構成要素に対する変更が他の構成要素に モジュール性 保 守 性 与える影響が最少になるように、システム又は コンピュータプログラムが別々の構成要素から 構成されている度合い。 コードの一つの構成要素に対する 変更が他の構成要素に与える影響 が最少になるように構成されてい る度合い。 一つ以上のシステムに、または他の資産作りに、 コードを他のプログラムに使用す 再利用性 【追加】 資産を使用することができる度合い。 ることができる度合い。 解析性 (略) コードの理解のしやすさ。 修正性 (略) コードの修正のしやすさ、修正に よる影響の少なさ。 (略) 修正したコードのテスト、デバッ グのしやすさ。 【名前変更】 試験性 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 22 「表 ソフトウェアの品質とコードの品質」の修正 (続き） 品質 特性 品質副特性 コードの品質 移 植 性 適応性 (略) 設置性 (略) 置換性 (略) 性 能 効 率 性 時間効率性 (略) 処理時間に関する効率性。 資源効率性 (略) 資源に関する効率性。 【追加】 セ キ ュ リ テ ィ 容量満足性 異なる環境への適応のしやすさ。 製品又はシステムのパラメータの最大限度 【追加】 が要求事項を満足させる度合い。 機密性 製品又はシステムが、アクセスすることを認 アクセスが認められたデータだけ められたデータだけにアクセスすることがで にアクセスすることができること きることを確実にする度合い。 を確実にする度合い。 インテグリティ コンピュータプログラム又はデータに権限をも プログラム又はデータ領域に権限 たないでアクセスすること又は修正することを、をもたないでアクセスすること又 システム、製品又は構成要素が防止する度合い。は修正することを防止する度合い。 否認防止性 事象又は行為が後になって否認されること がないように、行為又は事象が引き起こさ れたことを証明することができる度合い。 責任追跡性 実体の行為がその実体に一意的に追跡可能 である度合い。 真正性 ある主体又は資源の同一性が主張したとお りであることを証明できる度合い。 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 23 (2) C99への対応 C99の改訂に対応して、４ルールを追加、12ルールと2つのミス 例を修正 追加ルール 新規 R1.3.4 restrict型修飾子は使用しない。【MISRA C:2012 R8.14】 R3.1.3 指示付きの初期化子で初期化する配列のサイズは明示する。 R3.1.4 可変長配列型は使用しない。【MISRA C:2012 R18.8】 ミス例からルールへの変更 R3.6.3 sizeof 演算子は、副作用がある式に用いてはならない。 「可変長配列」の導入で、sizeof 演算子中の副作用の記載が常に無視される とは限らなくなったことに伴い変更。 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 24 C99への対応（続き） 修正ルール R 2.6.1 ビットフィールドに指定できる型の変更に対応 M1.3.3 暗黙の int 型の排除に対応して、解説、選択指針を変更 M1.5.2 <stdbool.h> の説明を解説に追加 M1.8.4 「代替綴り」に対応 M4.2.1 「//コメント」に対応して、解説に説明を追加 M5.1.1 「静的アサート」に対応して、解説に説明を追加 (C11） M5.1.3 「インライン関数」に対応して、解説に説明を追加 P 1.4.3 「//コメント」に対応 P 1.2.1 「識別子の拡張（国際文字名の使用）」に対応して、解説に説明を追加 P 2.1.1 「インライン関数」に対応 P 2.1.3 「long long」に対応 E 1.1.1 「インライン関数」に対応して、解説を修正 修正ミス例 ミス2 例4 値を返す関数の return 文の式の省略禁止に伴い、説明を追加 ミス3 例2 「複合リテラル」の導入に伴い、説明を追加 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 25 C99への対応 － 修正ルールの例（1） ビットフィールドに指定できる型の変更に伴い、ルールを選 択式とし、選択肢を追加 R2.6.1 (1)ビットフィールドに使用する型はsigned intとunsigned int だけとし、 1ビット幅のビットフィールドが必要な場合は signed int 型でなく、 unsigned int 型を使用する。 (2) ビットフィールドに使用する型はsigned int、unsigned int、または _Boolとし、1ビット幅のビットフィールドが必要な場合は、unsigned int 型 または _Bool型を使用する。 (3) ビットフィールドに使用する型はsigned int、unsigned int、 _Bool または、処理系が許容している型のうち signed と unsigned を指定 した型 またはenum型を使用する。1ビット幅のビットフィールド (2)、(3)を追加。(1)は、ESCR V1.1 と同じルールでC90の規格に沿っている。 (2)は C99の規格に沿うが処理系定義の型を使用しない、(3)は(2)に加えて処理 系定義の型を使用してもよいとしている。 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 26 C99への対応 － 修正ルールの例（2） //コメントの追加に対応して、解説の内容を修正 M4.2.1 《ファイルヘッダコメント、関数ヘッダコメント、行末コメント、ブロッ クコメント、コピーライトなどの書き方に関する規約を規定する。 》 （略） (4) その他 ・/* */ コメントと//コメントの使用方針を決める。 例1：文末コメントには「//」を、ブロックコメントには「/* */ 」 を使用する。 例2：「/* */」は閉じ忘れの恐れがあるので、「//」を使用する。 例3：コメント内で「/*」や「//」は使用しない。但し、//コメント 中の「//」は例外とする。 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 27 C99への対応 － 修正ルールの例（3） C11の「静的アサート」の追加に対応して、解説に情報を追加 C11の新仕様の内容を参考として追加 M5.1.1 《デバッグオプション設定時のコーディング方法と、リリースモジュール にログを残すためのコーディング方法を規定する。》 （略） (b) assert マクロを利用する方法 （略） C11では、コンパイル時に評価可能なアサートをソースコードに埋めてお き、構造体メンバのオフセットや文字定数の長さの確認をコンパイル時に 行うことができる。 _Static_assert (sizeof(t) <=4, “tのサイズが4バイトを超えている”); Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 28 (3) MISRA C:2012への対応 MISRA C:2004 ルール引用箇所への対応 MISRA Cの変更状況により以下の対応を実施(詳細次ページ以降） MISRA C：2012 変更状況 1) 変更なし ESCRの対応 ルール数※ 2) 表現が異なる、 引用ルールを MISRA C:2012に修正 又は一部修正 引用ルールの修正無し(MISRA C:2004のまま) 3) ルール削除 7 引用ルールを MISRA C:2012に修正 4(7箇所) 7 MISRA C:2004のルールをそのまま掲載 3 ルールを削除 1 ※ESCRの１ルールにMISRAのルールが複数含まれる場合重複カウントあり MISRA C:2012 追加ルールへの対応 次の３つのルールを引用して追加 (C99の改訂２、その他1） R1.3.4 restrict型修飾子は使用しない。【MISRA C:2012 R8.14】(C99) R3.1.4 可変長配列型は使用しない。【MISRA C:2012 R18.8】(C99) M4.7.7 #if または#elif 前処理指令の制御式は、0または1に評価されな ければならない。【MISRA C:2012 R20.8】 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 29 表現が異なる 又は 一部修正されている場合 ESCRの引用をMISRA C:2012のルールに修正 M1.7.1 (次ページ参照） M3.1.1 V2.0 繰返し文を終了させるために使用するbreak文 又はgoto文は1つま でとする。【MISRA C:2012 R15.4】 V1.1 繰返し文では、ループを終了させるためのbreak 文の使用を最大で も1つだけに留めなければならない。【MISRA 14.6】 M5.1.2 V2.0 （1） 前処理演算子#と##を使用してはならない。【MISRA C:2012 R20.10】 （2） #演算子の直後に続くマクロパラメータの直後に##演算子を続けな い。【MISRA C:2012 R20.11】 V1.1 （1） 前処理演算子#と##を使用してはならない。【MISRA 19.13】 （2）1つのマクロ定義内で#または##前処理演算子を複数回使用してはな らない。【MISRA 19.12】 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 30 表現が異なる 又は 一部修正されている場合（続き） M1.7.1 V2.0 名前の一意性は、次の規則に従う。 1. 内側のスコープで宣言された識別子は外側のスコープで宣言された識別子を隠しては ならない。【MISRA C:2012 R5.3】 2. typedef名は一意な識別子でなければならない。【MISRA C:2012 R5.6】 3. タグ名は一意な識別子でなければならない。【MISRA C:2012 R5.7】 4. 外部結合をもつオブジェクトや関数を定義する識別子は一意でなければならない。 【MISRA C:2012 R5.8】 5. 内部結合をもつオブジェクトや関数を定義する識別子は一意にするべきである。 【MISRA C:2012 R5.9】 6. 構造体及び共用体のメンバ名を除いて、あるネームスペースの識別子を、他のネーム スペースの識別子と同じ綴りにしてはいけない。【MISRA C:2004 5.6】 V1.1 名前の一意性は、次の規則に従う。 1. 外部スコープの識別子が隠蔽されることになるため、内部スコープの識別子には外部 スコープの同じ名前を使用してはならない。【MISRA 5.2】 2. typedef 名は固有の識別子でなければならない。【MISRA 5.3】 3. タグ名は固有の識別子でなければならない。【MISRA 5.4】 4. 静的記憶域期間を持つオブジェクトまたは関数識別子は再使用すべきではない。 【MISRA 5.5】 5. 構造体と共用体のメンバ名を除いて、あるネームスペースの識別子を、他のネームス ペースの識別子と同じ綴りにしてはいけない。【MISRA 5.6】 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 31 表現が異なる 又は 一部修正されている場合（続き） MISRA C:2004の表現の方がESCRの方針「厳密さよりもわか り易さを重視」に沿うと判断して、2004引用のまま掲載 例： R2.8.2 可変個引数をもつ関数を定義してはならない。 【MISRA C :2004 16.1】 MISRA C:2012 のルール <stdarg.h>の機能を利用してはならない その他、次のルールも同様の理由で2004引用のままとした M1.6.2、M3.3.1、M3.3.2、P1.1.2 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 32 表現が異なる 又は 一部修正されている場合（続き） MISRAのルールは修正されたが、2004のルールを残してよい と判断 M1.8.2 Cマクロは、波括弧で囲まれた初期化子、定数、括弧で囲まれた式、型修飾子、 記憶域クラス指定子、do-while-zero構造にのみ展開されなければならない。 【MISRA C:2004 19.4】 ルールがディレクティブとして説明に組み込まれたが、ルー ルとして明示する方がわかり易いと判断 P1.3.3 （1） ビットフィールドは使用しない。 （2） ビット位置が意識されたデータに対してはビットフィールドは使用し ない。 （3） ビットフィールドの処理系定義の動作とパッキングに（プログラム が）依存している場合、《それは文書化しなければならない。》 【MISRA C:2004 3.5】 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 33 MISRA C:2012 でルールが削除された場合 ESCRでルールを削除 M3.1.3 continue文を使用してはならない。 MISRA C で削除され、ESCRとしてもルールとして残す必要がない と判断。 ESCRでMISRA C:2004のルールをそのまま掲載 M4.7.5 マクロは、ブロック内で#define、または #undef してはならな い [MISRA C :2004 19.5] C言語初心者の中には#defineや#undefの有効範囲をブロック内と 勘違いするケースがあると考え、残すことにした。 その他、M1.5.1, M1.7.1（項番6）も同様に残している。 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 34 (4) その他の改善、文章の修正 その他の改善として、主に次を実施 作法表現の改善（JIS作成時の修正の反映） ルールの表現の修正、改定 ルールの明確化 C++版における修正を反映 解説への情報の追加 例の改善 作法表現の改善例 R2.2 V1.1では、ルール（ R2.2.1）と似た表現だったが抽象化 V2.0 論理値などが区間として定義されている場合、その中の一点（代 表的な実装値）と等しいかどうかで判定を行ってはならない。 V1.1 真の値と等しいかどうかを調べてはならない。 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 35 ルールの表現の修正、改定 ルールの表現の明確化や一部改訂の例 R2.8.3 ルールを明確化（ C++版と同じ表現に修正） V2.0 1つのプロトタイプ宣言は1箇所に記述し、それが関数呼出し及び関数定 義の両方から参照されるようにする。 V1.1 関数呼出し、および関数定義の前にプロトタイプ宣言を行う。さらに、 同じ宣言が関数呼出しと定義で参照されるようにする。 R3.3.2 ルールを改定（C++版と同じ修正を実施） V2.0 関数は、処理の開始前に引数の制約をチェックする。 V1.1 関数に渡す引数に制限がある場合、関数呼出しする前に、制限値でない ことを確認してから関数呼出しする。 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 36 ルールの表現の修正、改定（続き） M1.4.1 ルールの禁止事項を緩和（MISRA 2012との親和性を考慮） V2.0 &&演算や||演算の右式と左式は二項演算を含まない式か ( ) で囲まれた 式を記述する。ただし、&&演算が連続して結合している場合や、||演算 が連続して結合している場合は、&&式や||式を ( ) で囲む必要はない。 V1.1 && や||演算の右式と左式は単純な変数か( )で囲まれた式を記述する。 ただし、&& 演算が連続して結合している場合や、||演算が連続して結 合している場合は、&& 式や||式を( )で囲む必要はない。 単項演算、後置演算、キャストまでを()で囲むと、プログラムが読みにくくなる ことがあるため、ルールの制約条件を緩和した。但し、単項演算の中で！演算子 については、順序が分かりにくいことがあるため、次の説明を解説に追加してい る。 「なお、！演算については、初心者には優先順位が紛らわしいため、()で囲む というルールにすることも考えられる。」 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 37 4. 今後の活動 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 38 今後の活動 CERT CセキュアコーディングスタンダードとESCRルールの 対応関係の明確化 提供時期（予定）：2015年度 ESCR [C++ 言語版] の改定 改定内容 新言語規格 (通称 C++11) への対応 ESCR C言語版 改版（V2.0）との整合性の確保 MISRA C++ 改訂への対応 CERT C セキュアコーディングスタンダードとの対応の強化 提供時期（予定）：2015年度末 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 39 ご清聴、ありがとうございました 今後とも ESCR のご活用を よろしく お願いします Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 40 付録1：ESCR［Ｃ言語版］ V２.０ 書籍 名 【改訂版】 組込みソフトウェア開発向け コーディング作法ガイド [Ｃ言語版] Ｖｅｒ. ２.０ 編集・ 独立行政法人情報処理推進機構 発行 技術本部 ソフトウェア高信頼化センター 発行日 ２０１４年３月７日 サイズ Ｂ５変型判 ページ 数 １７３ページ ＩＳＢＮ 978-4-905318-23-1 定価 本体1,619円 （税抜） IPA直販と Amazonでご購入いただけます。 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 41 付録2：ESCR V2.0 [Ｃ言語版］ルール正誤表 ルール番号 誤 正 R3.4.1 【MISRA 16.2 】 R3.5.3 ループカウンタの比較に等価演算子 ループカウンタの比較に等価演算子 (==）、不等価演算子（!=)は使用しな (==、!=)は使用しない。 い。 M1.1.2 【MISRA C:2004 2.4 】 【MISRA C:2012 D4.4】 M1.8.1 【MISRA C:2004 12.4 】 【MISRA C:2012 R13.5】 M3.1.1 繰返し文では、ループを終了させるた めのbreak文の使用を最大でも一つだ けに留めなければならない。 繰返し文を終了させるために使用する break文 又は goto文は、1つまでとす る。 P2.1.1 <略> インラインアセンブリ言語のみ <略> インラインアセンブリ言語のみ が含まれるC言語の関数やインライン関 が含まれるC言語の関数として表現する、 <略> 数として表現する、<略> Copyright © 2014 IPA, All Rights Reserved 【MISRA C:2012 R17.2】 Software Reliability Enhancement Center 42 付録3：ESCR V2.0 主要変更作法・ルール一覧 V1.1 からV2.0で変更された作法とルールを示す。なお、軽微な 変更は含まない。 追加（ルール） ルール番号 概要 R1.3.4 ・C99の新仕様（restrict 修飾子）に対応 (MISRA C:2012引用） R3.1.3 ・C99の新仕様（指示付き初期化子）に対応 R3.1.4 ・C99の新仕様（可変長配列）に対応 R3.6.3 ・C99 の新仕様（可変長配列）で sizeof 演算子中の副作用の記載がミスとは限らなくなった ことから、sizeof 演算子の記述をミスからルールに変更 M4.7.7 ・MISRA 2012 の新ルール(R20.8)を追加 (MISRA C:2012引用） (MISRA C:2012引用） 削除（ルール） ルール番号 概要 M3.1.3 ・MISRA C 2004(R14.5)引用のルールであったが、MISRA C:2012でルールが削除された ため、削除 M4.7.4 ・M4.7.3 にマージしたため、本ルールは削除 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 43 修正（作法） 作法番号 変更概要 R2.2 ・表現の抽象化（改善、JIS X0180との表現の統一） M1.4 ・表現の修正（JIS X0180との表現の統一） M1.5 ・表現の抽象化（改善、C++版との表現の統一） M2 ・表現の修正（JIS X0180との表現の統一） 修正（ルール） ルール番号 変更概要 R1.1.1 ・ルールの表現を修正（明確化） R1.3.1 ・解説に情報を追加 R1.3.3 ・ルールの表現を修正（明確化） R2.6.1 ・C99の新仕様（_Bool型）、及び 変更（ビットフィールドに指定できる型）に対応 R2.7.1 ・ルールの表現を修正（明確化） ・解説を追加 R2.7.2 ・MISRA Cの引用を 2004 から 2012に変更 R2.8.2 ・解説に情報を追加 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 44 ルール番号 変更概要 R2.8.3 ・ルールの表現を修正（C++言語版における修正を反映） R3.3.1 ・MISRA Cの引用を 2004 から 2012に変更 ・解説を追加 R3.3.2 ・ルールを変更（改善、C++言語版における変更を反映） ・解説を追加 R3.4.1 ・MISRA Cの引用を 2004 から 2012に変更 R3.5.3 ・ルールの表現を修正（明確化） M1.1.1 ・ルールの表現を修正（明確化） ・解説に情報を追加 M1.1.2 ・MISRA Cの引用を 2004 から 2012に変更 M1.3.3 ・C99の変更（暗黙のint型宣言の排除）に対応して、解説、選択指針を変更 M1.4.1 ・ルールを変更（禁止すべき式を一次式以外から緩和） ※MISRA C:2012 における緩和を採用 M1.4.2 ・解説に情報を追加 M1.5.2 ・C99 の <stdbool.h> の説明を解説に追加 M1.7.1 ・[項番1～4] MISRA Cの引用を 2004 から 2012に変更 ・[項番5] MISRA C: 2012 のルールを追加 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 45 ルール番号 変更概要 M1.8.1 ・MISRA Cの引用を 2004 から 2012に変更 ・例を修正（改善） M1.8.4 ・C99 の新仕様（代替綴り）に対応して、ルール、解説、例を修正 M1.8.5 ・ルールの表現を修正（明確化） M3.1.1 ・MISRA Cの引用を 2004 から 2012に変更 M3.1.2 ・ルールの表現を修正 ・V1.1 のルールは、解説に移動 M3.3.1 ・解説に情報を追加 M3.3.2 ・解説に情報を追加 M4.2.1 ・C99の新仕様（//コメント）に対応して解説を追加 M4.3.1 M4.3.2 ・共通の解説に情報を追加 ・関連ルールを追加 M4.5.1 ・解説に情報を追加 M4.7.2 ・ルールの表現を修正（明確化） M4.7.3 ・M4.7.3 と M4.7.4 をマージ。M4.7.4は廃番とした M4.7.6 ・MISRA Cの引用を 2004 から 2012に変更 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 46 ルール番号 変更概要 M5.1.1 ・C11の新仕様（静的アサート）に対応して、解説に情報を追加 M5.1.2 ・MISRA Cの引用を 2004 から 2012に変更 M5.1.3 ・C99の新仕様（インライン関数）に対応 P1.1.1 ・ルールの表現からC90を削除 ・解説をC99に対応 P1.1.2 ・解説をC99対応 P1.2.1 ・ルールの表現からC90を削除 ・C99の「識別子の拡張」について解説に情報を追加 P1.2.2 ・例と解説を修正（明確化） P1.3.1 ・解説に情報を追加 P1.4.1 ・MISRA Cの引用を 2004 から 2012に変更 P1.4.3 ・C99の新機能（//コメント）に対応して、ルール、解説を修正 P2.1.1 ・C99の新仕様（インライン関数）に対応して、解説に情報を追加 P2.1.3 ・C99の新仕様（long long）に対応して、ルール、解説を修正 E1.1.1 ・C99の新仕様（インライン関数）に伴い、解説を修正 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 47 ルール番号 変更概要 ミス1 例5 ・解説に情報を追加 ミス2 例4 ・C99の新仕様（関数の型とreturn文の不整合の検出）に伴い、説明を追加 ミス3 例2 ・C99の新仕様（複合リテラル）に伴い、説明を追加 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 48 （参考）MISRA C:2004引用のままとしたルール ルール番号 ルール 理由 R2.8.2 MISRA 2012 では “<stdarg.h>の機能を利用し てはならない”という表現になったが、可変個引数 (1）可変個引数をもつ関数を定義してはならない。 をもつ関数を定義してはならないの方が ESCRの 【MISRA C:2004 16.1】 方針「厳密さよりもわかり易さを重視」に沿うと 判断 M1.5.1 関数識別子（関数名）には、前に&を付けるか、括 MISRA 2012 では、本ルールは削除。 弧つきの仮引数リスト（空でも可）を指定して使用 ESCRでは、意図を明示するという意味で「&」を しなければならない。【MISRA C:2004 16.9】 付けた方がよいと考え、本ルールを残した M1.6.2 M1.7.1 （1）共用体は使用してはならない。【MISRA C:2004 18.4】 （2）共用体を使用する場合は、書き込んだメンバ で参照する。 MISRA 2012 では “union”が“union キーワード” という用語になっているが、union キーワードを 使わない よりも “union を使わない”の方が ESCRの方針「厳密さよりもわかり易さを重視」に 沿うと判断 名前の一意性は、次の規則に従う。 (略） MISRA 2012 では、本ルールは削除。 6. 構造体及び共用体のメンバ名を除いて、あるネー ESCRでは、本ルールを採用する方が読みやすいプ ムスペースの識別子を、他のネームスペースの識 ログラムになると考え、本ルールを残した 別子と同じ綴りにしてはいけない。【MISRA C:2004 5.6】 Copyright © 2014 IPA, All Rights Reserved Software Reliability Enhancement Center 49 ルール番号 M1.8.2 M3.3.1 M3.3.2 ルール 理由 Cマクロは、波括弧で囲まれた初期化子、定数、括 MISRA 2012 では、本ルールは「キーワードと同 弧で囲まれた式、型修飾子、記憶域クラス指定子、 名のマクロ定義禁止」ルールに緩和されたが、 do- while-zero構造にのみ展開されなければならな ESCRでは、2004レベルの禁止の方が適切と判断 い。【MISRA C:2004 19.4】 for文の3つの式には、ループ制御に関るもののみを MISRA 2012 では、2004の 13.5, 13.6 はまとめ 記述しなければならない。【MISRA C:2004 られ「R14.2 for ループは適格（well-formes)で 13.5】 なければならない」になり、説明で詳細を規定し ている。ルールの意図は同じだが、ESCRでは、 forループの中で繰返しカウンタとして用いる数値変 2004の表現の方がESCRの方針の「厳密さよりも 数は、ループの本体内で変更してはならない。 わかり易さを重視」に沿うと判断 【MISRA C:2004 13.6】 M4.7.5 MISRA 2012 では、本ルールは削除。 マクロは、ブロック内で#define、または#undefし ESCRでは、初心者の中には#defineや#undefの てはならない。【MISRA C:2004 19.5】 有効範囲をブロック内と勘違いする場合があると 考え、本ルールを残した P1.1.2 《使用する処理系定義の動作はすべて文書化しなけ MISRA C:2012でもルールの意図は同じだが ればならない。》 【MISRA C:2004 3.1】 2004の表現の方がわかり易いと判断 P1.3.3 （3）ビットフィールドの処理系定義の動作とパッ キングに（プログラムが）依存している場合、 《それは文書化しなければならない。》 【MISRA C:2004 3.5】 Copyright © 2014 IPA, All Rights Reserved MISRA C:2012 ではルールがまとめられたが、 ESCRでは個別のルールも残した方がわかり易いと 考えた Software Reliability Enhancement Center 50
© Copyright 2024 ExpyDoc
