当然、現代のプログラミングの「疫病」と考えられている欠陥は克服されています。 フランスの科学者、プログラミング言語Eiffelの作成者、客員教授であり、イノポリス大学のソフトウェアエンジニアリング研究所長であるBertrand Meyerによる記事の翻訳を読むことをお勧めします。 元の記事は、ジャーナルCommunications of the ACMに掲載されています。
コードは非常に重要です。これについては、以前の記事で説明しました 。 プログラミング言語も同様に重要な役割を果たします。 Eiffelは契約による設計（「契約による設計」）の原則でよく知られていますが、それらは体系的な設計の一部にすぎません。その主な目的は、開発者が最大限の可能性を実現し、コードからクラッシュやエラーの原因を取り除くのを支援することです
失敗の原因については、nullポインターの逆参照に言及する価値があります。これは、現代のプログラミングの「ペスト」と正しく見なされる欠陥です。 この用語は、 xf呼び出しを行うときに発生する現象を指します。これは、「 xによって参照されるオブジェクトにコンポーネントf （フィールドまたは操作へのアクセス）を適用する」ことを意味します。 タスクが意味のあるデータ構造を定義する場合、参照変数の可能な値の1つとしてNilまたはVoidとも呼ばれるnullの使用を有効にする必要があります（たとえば、関連するデータ構造を完成させるには、最後のリストアイテムの「次の」フィールドをゼロにする必要があります次のアイテムがないことを示します）。 次に、 xf呼び出しがxのゼロ値に適用されないことを確認します。この場合、 fが適用されるオブジェクトがないためです。
この問題は、 xf形式の呼び出しが主要なメカニズムであるオブジェクト指向言語に非常に関連しています。 不確定な動作のリスクは、このメカニズムを使用するたびに発生します（この記事を読むまでに、このようなケースが何十億件も既に発生していますか？）。 ほとんどのプログラミング言語のコンパイラは、同様の性質の他のエラー、特に、変数に間違った値が割り当てられた場合など、宣言のタイプに関連するエラーをキャッチします。 ただし、コンパイラは、nullポインターの逆参照を防ぐことはできません。
ヌルポインターの逆参照は、最新のプログラムの実装を危険にさらす主要な脆弱性です。 Tony Hoarによると、nullポインターの逆参照は「 10億ドルのエラー 」です。 そして、これはまったく誇張ではありません。 Alexander Kogtenkovの博士論文では、インターネット攻撃に関する情報を含む典型的な脆弱性とリスク（CVE）のデータベースに基づいて、nullポインターの逆参照に関連する欠陥を調査しました。 この調査の結果は、年間の攻撃の総数を示すグラフに表示されます。
攻撃の数の背後には恐ろしい実例があります。 脆弱性の説明 CVE-2016-9113に基づく： convertbmp.cのimagetobmp関数のNULLポインター逆参照：980 OpenJPEG module 2.1.2 image-> comps [0] .dataは初期化後に値を割り当てません（NULL）。 その結果、サービス拒否が発生します。
はい、これはJPEG標準の場合です。 ネットワークに写真をアップロードするときは、考えないようにしてください。 わずか1か月（2016年11月）に、システムのデータベースには、 GoogleとMicrosoftから始まるIT業界のGotha製品に影響を与えるヌルポインターの逆参照に関連する脆弱性が記録されました（「理論的には、 Red HatおよびCiscoへの特別な「データパッケージ」）。 NVIDIAは次のようにコメントしました：NVIDIA Quadro、NVS、Ge-Force製品、および最大342.00のNVIDIA Windows GPUディスプレイドライバーR340バージョンと最大375.63のR375バージョンは、無効な入力によってNULLポインターの逆参照が引き起こされるドライバーの脆弱性（nvlddmkm.sys）を発見しましたユーザーの場合、サービス拒否または特権の昇格の可能性があります。
多くの場合、セキュリティとインターネットには互換性がないという不満があります。 しかし、問題が設計だけでなく（TCP / IPプロトコルスタックが正常に機能する場合）、これらのプロトコルを実装する手段を記述するために使用されるプログラミング言語の場合はどうでしょうか。
Eiffelプログラミング言語に関しては、この問題を解決する時が来たと判断しました。 以前は、型システムを使用して安全でない型変換を削除し、ガベージコレクションを使用してメモリ管理エラーを取り除き、SCOOPメカニズムを使用してデータ競合の欠陥を取り除きました。 NULLポインターの逆参照の問題を解決するときが来ました。 現在、Eiffelでは安全でない呼び出しの問題はありません。ここでは、nullポインターの逆参照は基本的に不可能です。 プログラムを受け入れることにより、コンパイラはxfが実行されるたびに、変数xが実際に存在する特定のオブジェクトを参照するようにします。
どうやってやったの？ この記事では、nullポインターの逆参照を防止する方法については詳しく説明せず、 ドキュメントのあるリソースへのリンクに限定します 。 また、メカニズムは常に改善されていることにも注意してください。 この記事では、主なアイデアについて説明します。 このトピックに関する最初の記事は、2005年のオブジェクト指向プログラミングに関する欧州会議（ECOOP）の基調講演になりました。 数年後、 記事の 1つで元のソリューションを確認し、次のように書きました。「ヌルポインターの逆参照に対する保護メカニズムに基づいて、ボイド安全技術の開発、改善、説明に数週間かかりました。 エンジニアリングには4年かかりました。」
楽観的に聞こえました。 7年後、「エンジニアリング作業」が続きました。 そして、ポイントは、nullポインターを逆参照から保護することではありません-メカニズムは当初、理論的には十分に正当化されていました。 コンセプトの長期にわたる改良の目標は、プログラマーの作業を促進することでした。 静的型付けなどのバグのないメカニズムは、次の公式に従って信頼性の高い保護とセキュリティを提供します：「悪意のある回路を禁止します（そうでなければ、欠陥は避けられません）。彼らの仕事の原則を変えることなく。」 いわゆる「エンジニアリング作業」には詳細な静的解析が含まれます。これにより、コンパイラは、より単純なソリューションでは拒否される安全な型を受け入れます。
実際には、ヌルポインターの逆参照に対する保護ソリューションの最適化の複雑さは、オブジェクトの初期化により関連しています。 メカニズムの詳細は常に改善できますが、アイデア自体は単純です。メカニズムは型宣言と静的分析に基づいています。
nullポインターの逆参照を防ぐためのシステムは、「付加」型と「分離可能」型を区別します。 特定のタイプ（たとえば、PERSON）で変数p1をタイプ化すると、ゼロになることはありません。その値は常にこのタイプのオブジェクトへの参照になります。 変数p1は「付加」されています。 これがデフォルトです。 変数p2をゼロにしたい場合は、「detachable」 -detachable PERSONとして指定します。 単純なコンパイルメカニズムはこの区別をサポートします。p1をp2に割り当てることができますが、その逆はできません。 したがって、「付加」式は真です。プログラムの実行中、 p1の値は常にゼロ以外になります。 コンパイラはこれを正式に保証します。
静的分析では、このような保証がはるかに多く、コードが安全であれば、プログラマー側の努力は必要ありません。 たとえば、コードが次のようになっている場合：
p2 / = Void then p2.f endの場合、すべてが正常であることがわかります（特定の条件下で。たとえば、マルチスレッドプログラミングでは、並列スレッドがチェックしてfを適用する間隔で変数p2をリセットしないことが重要です。これはルールによって提供されます。 ）
もちろん、メカニズムの実際の定義は、コンパイラが安全なケースを認識し、安全でないケースを拒否することを保証しません。 プログラムのセキュリティをプログラムツール（Eiffelコンパイラなどのオープンソースツールでさえ）だけに信頼することはできません。 さらに、単なるコンパイラ以上のものがあります。 無効な安全性の定義では、コンパイラが従わなければならない、認証済み添付パターン（CAP）と呼ばれる一連の単純で単純なルールを使用します。 前の例は、これらの認定テンプレートの1つを示しています。 機械化された証拠（Isabelle / HOLツールを使用）によってサポートされる正式なモデルは、初期化に関連するデリケートな問題を含むこれらのルールの有効性の強力な証拠を提供します。
ボイド安全技術は数年前から存在しており、それを使用した人は、以前のヌルポインター安全の方法に戻りたくありません。 安全なコードを作成することは、急速に一般的になりつつあります。
コードがnullポインターの逆参照から保護されていると確信していますか？