さまざまなレベルのコードで静的分析を実行する際のさまざまなトレードオフは何ですか? たとえば Java の場合、Java ソース コードとJasminコードと Java バイトコードの静的解析を実行するのはなぜでしょうか? その選択によって、実行できるさまざまなタイプの分析が制限または拡張されますか? 選択は分析の正確さに影響しますか? ありがとう。
4 に答える
さまざまなレベルのコードで静的分析を実行する際のさまざまなトレードオフは何ですか? たとえば Java の場合、Java ソース コードと Java バイトコードの静的解析を実行するのはなぜでしょうか?
ユーザーの観点から言えば、非常に具体的で形式化が容易でない限り、分析するプロパティ (純粋な安全プロパティなど) は、Java ソース コードをサポートするツールを使用することになります。
ツール開発者の観点からは、あるレベルまたは別のレベルで作業する方が簡単かもしれません。ここでは、私の頭に浮かぶ違いを紹介します。(コンパイラーおよび/またはまともな逆コンパイラーを使用すると、たとえばツールはあるレイヤーで動作し、別のレイヤーで結果を表示することに注意してください。)
Java ソースコードの長所:
- 任意のジャンプではなく、構造化言語、つまりループなど。(これにより、たとえば、最も弱い前提条件計算を作成することがはるかに簡単になります。)
- コードでより多くの仮定を行うことができます (バイトコード プログラムはより表現力豊かです)。
バイトコードの長所:
- 言語仕様 (バイトコード命令のセマンティクス) ははるかに単純です。
- マシン (VM) のより「固定化された」仕様
- 分析をレガシ コードおよびライブラリに拡張できます。
- 分析により、JVM をターゲットとする他の言語 (Closure、Scala、JRuby...) が可能になります。
- おそらく複雑なパーサーは必要ありません
機械語の長所:
- 実際に何を CPU に供給しているかを検証します。(完全に検証されたチェーンが必要な場合は、検証済みのコンパイラまたは検証済みの VM を使用する必要はありません。)
Spec#など (C# のフォーマル メソッドの方言)などの最先端のツールは、通常、フォーマルな分析用に特別に設計された中間言語(BoogiePL (Spec# の場合は MSIL または C# に近い)) を使用します。
その選択によって、実行できるさまざまなタイプの分析が制限または拡張されますか?
結局のところ…いいえ、そうではありません。どの (チューリング完全な) 言語を分析対象として選択しても、同じ根本的な問題に直面します。分析するプロパティによっては、YMMV.
正式な方法に興味があり、自分で分析を実装することを考えている場合は、バイトコード用のより優れたツール サポートを見つけることができると思います。あなたがユーザーまたは開発者であり、独自のコードベースで分析を実行したい場合は、Java ソース コード レベルで動作するツールからより多くのメリットが得られると思います。
選択は分析の正確さに影響しますか?
正しさの意味によって異なります。静的分析は、ほとんどの場合、自分が知らないことはすべて真であると想定しないという意味で「防御的」です。注意を健全な検証システムに限定すると、それらはすべて「等しく正しい」ものになります。
IntelliJ には、バイトコードでは利用できない Javadoc やパラメーター名などのコメントの静的分析があります。たとえば、スペルミスや名前の不一致などです。コードの分析により、行番号と問題のある行内の位置を確認できます。
バイトコードを分析する利点は、それがはるかに単純で、必要なものがすべて揃っていることです。行番号はあるかもしれませんが、位置はありません。また、ソースがないコンパイル済みコード (ライブラリなど) を分析することもできます。
もう1つの考慮事項は、「抽象化により高レベルの情報が失われる」ことです。ソースコードで式が発生する場所が必要なので、ソースコード(高レベル)で行っています。
ソースからバイナリへのマッピングは、ソース コードの視覚化領域で非常に重要です。
さまざまなレベルのコードで静的分析を実行する際のさまざまなトレードオフは何ですか? たとえば Java の場合、Java ソース コードと Jasmin コードと Java バイトコードの静的解析を実行するのはなぜでしょうか?
このように考えてください。Jasmin またはバイトコードから否定的な結果 (否定的または有害な属性を示すまたは示唆する結果)を取得した場合、それについてどうしますか? タイムリーで費用対効果の高い方法で、どのように対処しますか?
ここで、ソース コード(ほとんどの場合、ソース コードまたは所有しているコード) の静的解析が戻ってきて、対処が必要な否定的/有害な属性を報告するシナリオを考えてみますか?
ソースコードにマッピングされているこの有害な側面に対処するのは、有害な側面 (おそらく類似または関連) に同じことをするよりも難しいと思いますが、今回はバイトコードまたは Jasmin にマップされますか?
問題は、1) Jasmin が正当なバイトコードの 1 対 1 の表現であることが期待されていること、および 2) バイトコードが正真正銘のコンパイラによって生成されていることです。適切に動作するコンパイラーが存在する場合、バイトコードの問題がソースコードで導入された問題に直接マップされる可能性は非常にわずかです。
バイトコード レベルで検出された問題が、ソース コード レベルで導入された問題の結果であるか、コンパイラ/環境の欠陥の結果であるかに関係なく、これらの問題は通常、対処できません(sp?)。通常、少なくとも直接的には、それに基づいて行動することはできません。
ソース コード レベル (OTH) で検出された問題は、効率的に対処できます。つまり、それを手に入れて修正することができます (そして、推論により、前者から派生したバイト コードの問題をすべて取り除くことができます)。
バイト コード レベルで、特にパッケージングのコンテキスト (不要なライブラリのパッケージ化) で検出できるものがあります。しかし、バイト コード レベルで検証を行う必要はほとんどありません。
コンパイラーと言語設計 (この場合は VM を対象とする) のビジネスに従事している場合を除き、効率と実用性のために、1) コンパイラーが正しいと仮定し、2) JVM の仕様を考えると、また、コンパイラがコンパイル時に検証を実行し、JVM が実行時に検証を行うと仮定します。
その選択によって、実行できるさまざまなタイプの分析が制限または拡張されますか? 選択は分析の正確さに影響しますか? ありがとう。
正しさをどのように定義しますか?この文脈での正しさとは何ですか?そして、それは正確さにどのように影響しますか? 型システムレベルでの正確さについて話しているのでしょうか? 部分的および/または全体的な正しさ? 公平性、活発さなどの属性に対する正確性は?分析プロセス自体の正しさ?1 つまたは複数の要件を満たすことに関する正確性は?
あなたの用語を定義してください:)
とにかく、コンパイラーがコードをターゲット命令セットに十分に正しく変換していると想定する必要があります (コンパイラー/言語設計のビジネスをしている場合を除きます)。
コードの「ネイティブ」表現が正しい (つまり、目的のターゲット プラットフォームと型システムに従って「マップ」されている) という前提で作業する場合、検証の範囲をソースに絞り込むことになります。検証する属性のコード。