今年の1月，C++ の開発者である Bjarne Stroustrup 氏が，C++ の言語仕様自体に大きな仕様変更を入れることを提案しました．プログラミング言語としての「安全」を考慮した仕様変更で，特に「メモリ安全」を確保することが主な目的になるようです．

周知の通り，C++ の仕様をめぐっては，これまで何度もメモリ安全にまつわる安全性が問題になってきました．今回の提案は，それにもとづくものではあるようですが，しかし，今回の動きは，プログラミング言語をめぐる，各界の対立関係を反映したものかもしれない，とのことです．

C++ 言語は，いうまでもなく，世界でもっともよく使われているプログラミング言語のひとつです．2023年2月の TIOBE Index を見ても，C++ のインデックススコアは 13.94% を占めており，全体の第3位に入っています．しかし，その C++ 言語が，新たな仕様を策定するにあたって，混乱しているようです．

記事によると，ことの発端は，Bjarne Stroustrup 氏の参加する direction group (DG) が，“profile” と呼ばれる機能を提案したことにありました．DG というのは，C++ の将来的な進化について勧告を行なう機関です．“profile” という機能は，その DG が “DG OPINION ON SAFETY FOR ISO C++ [PDF]” という書面で明らかにしたものです．

これによると，“profile” という言語機能は「強制されるプロパティを定義する制限と要求の集合」(a collection of restrictions and requirements that defines a property to be enforced) と定義される機能です．イメージとしては，コード中の特定のセクションを「安全」なセクションとし，そのセクションに対して，外部定義した静的解析/動的解析の機構を組み込むようなもののようです．

C++ が使われる開発現場は非常に多岐にわたっており，「安全」と一言でいっても，さまざまな安全がありえます．同氏によると，「メモリ安全」という概念も，その「安全」概念のひとつにすぎず，使用される局面に応じて，安全の概念を定義することがある，とのことです．そこで，各界に応じた「安全」を実現するために，安全の定義をそれぞれに応じた形で定義できるようにしましょう，というのが基本的なアイデアです．

実際，C++ の世界には，安全な実装を行なうためのコーディング標準が各業界あります．例えば，次のような標準です．

名前	説明
MISRA	自動車関連団体によって策定されたコーディング標準
JSF++ [PDF]	航空機における電子制御系開発のためのコーディング標準
CERT	SEI によるセキュアコーディングの標準
HICPP	Programming Research Limited による標準
AUTOSAR [PDF]	自動車メーカ，半導体，ソフトウェア業界などの標準
C++ Core Guidelines	Bjarne Stroustrup 氏と Herb Sutter 氏による標準

文書から具体的な内容は明らかでありませんが，Stroustrup 氏らは，このようなコーディング標準を言語仕様に取り込んだ形で，将来の仕様を策定しようとされているようです．

一方，このような標準に準拠しているか，静的にコードをチェックするツールとしては，これまでもサードパーティ製品が数多くリリースされてきました．例えば，Microsoft の Visual Studio などには，コード分析の機能がありますし，少し古いところでは，GCC にも “Effective C++” に準拠しているか解析するオプション -Weffc++ などがあります．また，自動車業界など，製品の安全性が特に求められる業界などでは，上記のような標準に準拠しているか，静的に解析するツールが数多くリリースされています．

これに対して，同文書では，このようなコンパイラオプションやサードパーティ製ツールに加え，C++ の言語機能として，あらかじめ定義された制限と要求に準拠しているか，チェックする機能を付加する方針のように読めます．

We now support the idea that the changes for safety need to be not just in tooling, but visible in the language/compiler, and library. We believe it should be visible such that the Safe code section can be named (possibly using profiles), and can mix with normal code. Individual features may not be very visible, but will be more visible when package.

[私たちは，安全のための変更が，単にツールだけにとどまらず，言語，コンパイラそしてライブラリによって可視化される必要がある，といったアイデアを支持します．つまり，「安全な」コードセクションに名前を付けることができ (これはおそらく profile を使用します)，通常のコードと混在させることができることを，可視化すべきであると考えています．個々の機能はよく見えないかもしれませんが，これらをパッケージにすれば，よりよく見えるようになるはずです．]

DG OPINION ON SAFETY FOR ISO C++

さて，それでは，そもそもなぜ，このような変更を求めることになったのでしょうか．

前掲記事によると，どうやらこれは，C++ だけの問題というよりも，むしろ，他の開発言語ベンダも含めたプログラミング言語間の対立と，それにともなう，アメリカ政府の方針が根本にあるようだ，と見ているようです．

ここ数年，長らく，C++ に対しては「メモリ安全」に対する批判がありました．メモリ安全というのは，メモリ周りのバグが作り込まれることを防ぐ仕組みがあることをいいます．メモリ周りのバグの多くは，ポインタの扱いによるもので，例えば，解放済みのメモリ領域を参照してしまったり，逆に解放し忘れたり，あるいは参照できない領域を参照してしまったりするようなバグのことです．

これに対し，昨今は，Rust や C# など，メモリ安全をウリしたプログラミング言語が多く世に出るようになりました．特に，Rust などは C++ と比較してメモリ安全を強調することが多く，支持を集め始めています．

このことに対応し，アメリカの標準機関である NIST が，安全保障上の問題として「メモリ安全」の問題を取り上げたのでした．この文書には，以下の文言があります．

The language institutes automatic protections using a combination of compile time and runtime checks. These inherent language features protect the programmer from introducing memory management mistakes unintentionally. Examples of memory safe language include C#, Go, Java®, Ruby., Rust®, and Swift®.

[この言語は，コンパイル時と実行時のチェックを組み合わせて，自動的に保護します．このような言語固有の機能によって，プログラマが意図せずにメモリ管理のミスを犯すことを防ぎます．メモリ安全な言語の例としては，C#, Go, Java®, Ruby., Rust®, and Swift® などがあります．]

Software Memory Safety | National Security Agency [PDF]

近頃叫ばれている通りの文言ですね．

さて，視点を変えて，この文書の最初の方を読んでみましょう．これを読むと分かるのですが，この文書が寄って立っているメモリ安全に関するデータは，Microsoft の調査結果と Google の調査結果が提供しているものなのです．例えば，Google の調査結果によると，深刻なセキュリティバグのうち，およそ70%はメモリ周りに関するバグであり，それらは，C/C++ におけるポインタの誤使用によるものだった，としています．

そこで，冒頭記事では，C++ のメモリ安全対応は，このような外部要因が大きく影響しているのではないか，と考えているようです．つまり，他の「メモリ安全」を標榜する言語が，言語仕様としてメモリ安全を謳うからには，C++ も言語仕様として「安全性」を確保したものでなければならない．そうであるならば，これまでの資産であるサードパーティ製のチェッキングツールは残しておくとしても，言語自体が安全であることを主張できないといけない，といったところなのでしょう．

C++ の仕様変更について，まだ具体的な動きはないようです．しかし，将来的に，これらを織り込んだ仕様変更があるかもしれないので，用意しておくといいかもしれません．