October 10, 2023

MISRA C++:2023®​について知っておくべきこと

*本記事は Perforce Software社の以下のブログ記事(2024年4月15日時点)の参考訳です。
 What You Need to Know About the Next MISRA® Standard: Introduction to MISRA C++:2023®
*ブログの内容は更新されている可能性があります。

MISRA C++:2023®は、2023年後半にリリースが予定されている、MISRA C++規格の待望の新版です。AUTOSAR C++ 14ガイドラインの内容が統合されるだけでなく、新しいバージョンのC++言語への対応も予定されています。

MISRA®のCおよびC++コーディングガイドラインは、自動車業界に限らず、組込みシステムを使用するあらゆる業界において、非常に重要な標準規格です。

新しいMISRA規格のリリースに備えて、MISRAの専門家であり、新版の公開レビューにも参加したDr. Frank van den BeukenがMISRA C++:2023について概説するブログシリーズを今回スタートします。

MISRA C++® とは

現行バージョンのMISRA C++は、2008年に初版が発行されたもので、C++言語(ISO C++ 2003)で記述された安全関連ソフトウェアの開発における専門的なガイドラインの役割を果たしており、セーフティクリティカルな開発プロジェクトの多くで採用され、その準拠が義務付けられています。しかし、初版の発行から年月が経ち、新しい言語機能の導入や既存機能の変更などにより、C++言語は大きく変化してきました。

新しいバージョンのC++言語を使用しているプロジェクトでは、MISRA C++:2008のルールすべてに適合することが難しく、新しい機能がカバーされないことがあるでしょう。このようなケースに対応するために、MISRA C++:2008をベースに他の規格のルールを追加したC++14用の新しいガイドラインがAUTOSARにより作られました。MISRA C++ワーキングループでは現在、このAUTOSARのガイドラインをベースに、MISRAが確立した安全なC++開発のベストプラクティスを包含する形で、C++17に対応した新たなMISRA C++規格のリリースを目指しています。

新しいMISRA C++ガイドラインに対する関心は非常に高いものの、多くのプロジェクトで既にMISRA C++:2008が採用されているため、新ガイドラインへの切り替えの影響を懸念する声もあります。

このMISRA C++:2023® ブログシリーズについて

このブログシリーズでは、以下のような側面からMISRA C++:2023®について解説します。

C++とMISRA C++の歴史

まず、1979年にベル研究所でBjarne Stroustrup氏によって考案されてから、1991年の標準化を経て、現在のバージョン(C++20)に至るまで、C++プログラミング言語がどのように進化してきたのか、その歴史を簡単に振り返ります。

興味深いのは、C++20で追加された主要な機能のいくつかは、かなり以前から既に議論されていたものであるということです。今回新たに導入された「モジュール」や「コンセプト」は、並行プログラミングのために必要となる標準的な機能であり、ライブラリ実装やコルーチンを提供します。並行プログラミングが規格の一部としてサポートされたのは今になってですが、上記の機能は元々、プログラミング構成とともに、C言語の開発効率を高めるために用いられていた、Simulaプログラミング言語の機能でした。

ただ、MISRA C++はC++17の方をベースにしているようです。これは恐らく、すべての言語機能をコンパイラ実装でサポートするには時間がかかり、さらに実装にあたってはセーフティクリティカルなプロジェクトで使用するための認証も必要になってくるからだと考えられます。

今まで、様々なC++コーディングスタンダードが作成されてきました。AUTOSARガイドラインについては既に述べましたが、その他にも一般的に使用されているコーディングスタンダードが数多くあります。Perforce Software社では毎年、自動車向けソフトウェア開発の現状やトレンドに関するアンケート調査を実施しており、2023年は400名近くの自動車業界の関係者から回答を集めました。そのアンケート結果を見るに、電気自動車や半自律走行車の開発が増え、それに伴いソフトウェアのコンポーネントも増加傾向にあることから、安全性と同様に、セキュリティを主な懸念事項として重要視する意見が引き続き多くあることが分かりました。この現状は、セキュリティ関連規格への準拠を求める要件の増加にも表れています。

この調査結果をまとめたレポートによれば、回答者の42%がMISRAを使用しており、依然として自動車業界で広く使われていることが分かります。自動車業界に深く根ざしてきたMISRAの長い歴史を考えれば、これは当然のことと言えるでしょう。AUTOSARを使用していると答えた回答者は36%で3位だったのに対して、自動車業界に直接的な関係が無いにもかかわらず、C++ Core Guidelinesが39%で2位というのは驚きの結果です。この規格の使用が多くなったのは、開発者たちが使用したいと考える最新のC++言語機能がカバーされているからかもしれません。

どのコーディングスタンダードを使用していますか?
引用:"『2023年版 自動車向けソフトウェア開発の現状調査レポート』"より

C++コーディングスタンダードについて

Bjarne Stroustrup氏とHerb Sutter氏によって立ち上げられたC++ Core Guidelinesは、現在でも継続的に改善がなされているドキュメントです。最新のC++言語機能をカバーしているため、AUTOSARのベースのひとつにもなっています。AUTOSARには、C++ Core Guideliensとの比較も記載されており、両者のルール間で合致しない部分が30%程あることが示されています。MISRA C++:2023は、AUTOSARの問題と考えられている部分のほとんどをカバーしているのに加え、直接的にC++ Core Guidelinesを使用していません。

これらのC++コーディングスタンダードの理念やガイドライン、コンプライアンス対応などをまとめたブログ記事も今後公開予定です。MISRA C++:2023でAUTOSARルールのすべてが網羅される可能性は低いでしょうから、C++ Core Guidelinesと異なる点をピックアップして、その部分をAUTOSARと比較していくような形で、MISRA C++:2023を評価していこうと考えています。

MISRA C++:2023向けの新しいガイドラインについて

本ブログシリーズでは、新しいガイドラインについても特集する予定です。

MISRA C++:2023では、クラス型のインタフェースを定義するためのルールが提供されています。また、コンパイラによって既に意図した実装が提供されていることが既存の言語標準により確実な場合、特殊なメンバ関数を指定することを良しとしない、"Rule of Zero"(ゼロの法則)を推奨しています。

このルールは、特殊メンバ関数はすべて常に明示的に指定する必要があるとする"Rule of Five"(5の法則)、デフォルトのコンストラクタも数に入れるのであれば"Rule of Six"(6の法則)のような他のガイダンスと矛盾することになります。新しいルールにおいて、既存のガイダンスでカバーされていた脆弱性がどのように対処されているのかについても考えたいと思います。

また、この対処の仕方には、AUTOSARルールA12-0-1の準拠例に見るようなリスクがあることも認識しておく必要があります。

class A // Compliant - the class A follow the "Rule of six" rule
  {
  public:
   A(); // Non-default constructor
   ~A() = default;
   A(A const&) = default;
   A& operator=(A const&) = default;
   A(A&&) = delete;
   A& operator=(A&&) = delete;
  };

この例では、move関数だけが削除され、copy関数とデストラクタはデフォルトになっています。これは、開発者が「3の法則」に従ったコードを「5の法則」に拡張しながらも、新しいmove関数を削除することで以前の動作を維持しようとした結果かもしれません。このような特殊なメンバ関数の組み合わせは、MISRA C++では許容されません(copy関数がクラスによって提供されている場合、move関数も提供される必要があるとされるため)。クラスは、コンテナとは一緒に使用できないことになっています。例えば、特定の型のベクターを宣言しようとした際に、move関数が不足しているとコンパイルエラーが発生します。なお、この例は、AUTOSARの18-03リリースで修正され、ルールの文言も変更されましたが、copy関数を使用する場合のmove関数の提供については明示的に要求されてはいません。

MISRA C++:2023では、異なるデータの型の間での自動的な変換(標準変換)の使用を制限するガイドラインが設けられる予定です。MISRA C:2012に慣れた開発者であれば、MISRA Cの本質型で定義されているのと同様の型変換ルールがあるものと期待するかもしれませんが、そうはならないようです。

MISRA C++:2023が、MISRA C:2012よりもかなり厳しいものになるのには理由があります。C言語と異なり、C++言語では関数のオーバーロードが可能になりますが、これには式が厳密な型を持っていること、そして式から型が自動的に推論されるautoプレースホルダー型指定子が使用されていることが前提となります。このルールに従っていない場合、ヘッダーファイルをインクルードすることで、以前マッチした関数よりもマッチ度が高い関数オーバーロードが予期せずに実現する可能性があります。暗黙的な変換を回避する方法としては、定数を列挙型として定義しておくことで型の安全性を保証するやり方があります。このように強い型の値であれば、暗黙の変換の対象にはなりません。

Helix QACで確実にMISRA規格に準拠しよう

Perforce Software社の「Helix QAC」は、MISRA CおよびMISRA C++のコンプライアンスチェックをはじめ、様々な解析機能を備えた静的解析ツールです。

MISRA CおよびMISRA C++の全エディションとリビジョンに対応したコンプライアンスモジュールが用意されており、MISRA C++:2023コンプライアンスモジュールも、同規格のリリースに合わせて提供開始予定です。

star MISRA C++:2023コンプライアンスモジュール is Available Now!! star

MISRA C++:2023コンプライアンスモジュールは既に日本でも提供を開始しています。ご興味のある方は、製品ページをご覧いただくか、以下までお問合せください。

■ お問い合わせ先 ■

株式会社東陽テクニカ ソフトウェア・ソリューション

phone 03-3245-1248(直通) mail ss_sales@toyo.co.jp