Scribble at 2025-09-15 07:36:49 Last modified: unmodified

C が安全でないのは知られているし、C++ が安全でないことも有名で、それゆえ組み込みを始めとして多くの実績があるにも関わらず、とりわけウェブ・アプリケーションの技術者には、あからさまに「C/C++ 嫌い」というスタンスをとって、システムを実装するなら Java だと言う人がいる。もっとも、ウェブ・アプリケーションの技術者というものは、その大半がスクリプト言語を扱う「言語のユーザ」でしかないので、別に彼らはスクリプト言語の処理系にアクセスして C/C++ のコードを扱っているわけでもないのだから、C とか C++ なんて殆ど使わないわけで、文句や批評を述べる資格などない。

でも、どういうわけか C/C++ は（とりわけメモリの処理について）危険であるという雑なフレーズだけが蔓延しているせいで、昔から「セキュア・コーディング」と言えば殆ど C/C++ の話であるというのが定番だった。僕も、新聞のサイトで広告を表示するプログラムを書いたときに（なぜか C の CGI として書くことを神戸新聞のエンジニアから必須の要件とされたのだ。もう15年以上も前の話だし NDA すらないから、具体的な話として書いておく）、僕が C でコードを書くのは問題ないとしても、可能な限り脆弱性を考慮しておこうとして、オライリーから出ていた C/C++ のセキュア・コーディングに関する本などを熱心に読んだ記憶がある。

というわけで、いまだにかような話題が C/C++ についてだけ常に独り歩きしていて議論の的になっている。本来は、どういう言語であろうと考慮して議論するべきことだし、少なくともコーダやプログラマという職能あるいはステージではなく、非機能要件も含めて仕事をするべきソフトウェア・エンジニアや IT アーキテクトであれば、常に考慮しておくべきことでもある。僕のように、受託ではキャンペーンなどのプロジェクト全体に関わるような観点（景品表示法や個人情報保護法など法務という観点も必要だ）も必要とする、さらに広範な守備範囲のプロダクト・マネージャとかサービス・アーキテストという立場では、逆に範囲が広すぎて雑な知見しかもっていない人が多いわけだが、セキュア・コーディングへの関心を欠いてはならないだろう。

だが、それを言語の仕様として採用するという話題になると、もちろんだが僕らの責任を超えてしまう話であり、どういう仕様を選ぶかというよりも、どういう仕様の言語をプロジェクトで採用するかという処理系の選択という問題になってしまう。たぶん、実際に処理系を利用しているユーザからのフィードバックなんて、規格を検討している人々は考慮しないでああろう。企業からの誘導的なコメントとか圧力から独立でなくてはいけないのだから、安易に善人ぶって「みなさんのご意見を集約する」だのなんのと、自民党の政治家がド田舎で支援者の話を聞くようなパフォーマンスでは意味がない。

Safe C++ という提案だと、安全なコンテクスト（ちょうど Perl の "use Safe" モジュールのような）を選ぶことになるが、対して C++ 標準化を策定する委員会ではプロファイルを採用して、コンパイルでの制約を加える方を好むという。どちらも既存のコードを変える必要がない後方互換性をもつわけだが、Safe C++ では言語の仕様を変えることとなるので実装が複雑になるという点が懸念されていて、プロファイルでは Rust のような言語の安全性が保証されないという点が懸念されている。ただ、著者は「何もしないよりはいい」という立場で、実装しやすいプロファイルを支持しているようだ。