関数コントラクトやアノテーションについて、MISRA WGで現在検討し、ドキュメントを作成中で、それにより詳細を公開することになる。
関数コントラクトのようなことを紹介することに少々不安もあったが、見識をお持ちの方が多く、質問・意見を得られて嬉しい。得られた多くの意見をMISRAにフィードバックして共有したいと思っている。

 概要の補足
現在、MISRA C++ WGでその方面の専門家が検討しているもの。C++のコードを使用せずに関数の挙動を記述する方法であり、
　- MISRAに準拠していないコードを含めることができる、
　- 静的解析ツールが真の問題を検出する上で役に立つ、
という利点がある。
関数コントラクトは他の言語でも使われてきたものであるが、使われ方がプログラマーにとって理解しやすいものではなかった。C++でアサートを使ってプログラミングを行うことがあるが、これと似ている点もある。
関数コントラクトについて導入への不安もあるが、使い勝手もよく有用性は高いと考えられる。
 
 形式的な証明との関連を想定しているか？
事前、事後条件を形式的な証明で使うというよりは、それらを設定することによってツールが結果を判断できるようにするもの。ツールの中には証明によってコントラクトの検証を行うものもあるだろう。
 
 コントラクトには他の条件（マクロ）としてインバリアントなどはあるか？
現在検討を進めており、インバリアントが上がっている。振る舞いを保証するものではなく、静的解析の品質を上げるものであると認識している。完全ではないが、これまでの方式よりもバッファオーバーランのようなエラーの可能性を検出したいと考えている。
 
 流用コードを扱う上で、今後、関数コントラクトが不可欠な要件になるのか？
MISRAではまだ関数コントラクトの使用を決定しているのではなく、現在、リサーチの対象となっている。有用性が高いので使うべきと考えるが、複雑であり使いづらいのではとの意見もWGにある。皆様の意見があればMISRAに持ち帰ってフィードバックして進めたい。
 
 コントラクト（preやpost）の部分はマクロということだが、これは静的解析ツールが認識するものと考えてよいか？
そのとおりで、静的解析ツールが扱うもの。それ以外のツールでは検出対象とはならない。
 
 静的解析ツール開発者にその機能を要求するのか？ ユーザーもそれらマクロを習得するのか？
ツールベンダに依頼することになる。
ユーザーも意識する必要がある。ただ、作成中のドキュメントで「マクロ」としているが、現時点で必ずしもマクロで表現されると決まっているのではなく、シンタクスも最終決定されてはいない。
ドキュメントでは、マクロに対して様々な理解を求めているのではなく、ユーザーがシンタクスについて理解することが前提となるとしている。

 モデルベースでコード開発しているが、モデルから生成されたコードはオリジナルかそれとも流用か。コード生成の設定で違反しないコードを出せるが、どこまで頑張るべきか？
MISRAでは自動生成されたコードについての制約を低く設定するガイドラインを過去に出しているが、その再検討を始めた段階である。
現時点で、MISRA WGで議論中であり、どうするかは決まっていない。プロジェクト用に自動生成されたコードであっても、そのためのコードやテンプレートが別プロジェクトで開発されていることもあるので、欠陥を含む可能性がある。名前の衝突などもあり得る。
そのようなコードに対して関数コントラクトを持つ流用コードして扱うのが良いかもしれない。マニュアルでのコードレビューを勧めることもある。テンプレート生成を検証するオプションを勧めることもある。

 流用コードとしてオープンソースを使用する場合、ツールで調べるが、MISRA違反が見つかった場合にどう対処するか？
完璧な回答は用意できないが、どのオープンソースを使用しているかにもよる。自動車業界のオープンソースではMISRAに準拠して作ろうとする動きがある。しかしそういった方向性を持たないオープンソースを使えば大量のMISRA違反が出るだろう。その場合、講演で話した再分類を行うことが考えられる。例えば、「推奨」を「非適用」にするなど。
また、影響の重大性により、「必須」にフォーカスしたチェックをまず行うことを勧める。そして、MISRA準拠を示すことか、単に品質の高いコードを得ることかどちらに重点を置くかによるが、「必要」の違反に対してチェックをかけることを考える。MISRA準拠を重視するなら「必須」「必要」を守ることが必要。
ツールで検出される違反であれば、対処は難しくないと考える。アンディサイダブルに対するチェックは人手で行うことが必要。それ以外の対処方法としては、現状まだ使える状況ではないが、関数コントラクトの利用があるだろう。

 MISRAとCERTの対応関係ドキュメントが発行されているが、MISRAではどのような観点でCERTのルールを取り入れる/入れていない のか？
MISRAではコア言語の振る舞いに重点を置いている。POSIXやWindowsのAPIに関するものはMISRAには入らない。MISRAではAPIは見ないが、リターン値（エラーコード）は、値を適切に扱っているかどうかということでチェックの対象になる。
セキュリティに関する問題のほとんどは未定義に関することで発生している。セキュリティ関連のガイドラインでは、バッファオーバーフロー/アンダーフローなどに関する特定のエラーに注目しているが、MISRAでは「バッファ上限を超えない」という（一般的な）ルールになる。
また、C/C++言語に関係しないものについてMISRAには含まれない。ライブラリの不適切な使用に関わらないようなルールのチェックは含む。

 取得者との間でどこまでやるのか話し合うというのがあったが、自社オリジナルで取得者がいない場合にどうなるか？
オリジナルの開発で取得者がいない場合は、自社内のQCを取得者として行うこともできる。 ほとんどの「必要」区分は再分類して「必須」となるべきである。MISRAのベーシックなレベルでチェックし、結果を見て違反がなければ「必須」にあげることもできる。（マーケットの観点では、コードを変更せずに質を上げたといえる）。
時間が経過するととともにハードウェアレジスタへのアクセスや、動的メモリの使用に関する違反が出てくるかもしれないが、限られた数だと思う。