`A5-0-1`: False positive related to overeager alias analysis

オープン
#1,047 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
cpp
領域
devtools

調査の方向性

まず SideEffects ライブラリと影響を受ける A5-0-1 分析から始め、次に localFlow と AliasParameter への参照を調べます。提示された例を、式の副作用および関数呼び出しの副作用の扱い(RULE-13-2 のケースを含む)と比較します。エイリアス解析が誤った未順序化の副作用を報告しなくなり、関数パラメーターを介した本物の影響を引き続き検出できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

false positive/false negative
Affected rules
  • A5-0-1
  • Likely others such as RULE-13-2 under more atypical conditions
Description

We can produce false positives related to unsequenced side effects from overeager alias analysis.

The SideEffects library attempts to capture side effects across function boundaries:

void f(int *i) {
  (*i)++; // side-effect (*i)++
}

void g() {
  int i;
  f(&i); // side-effect: (*i)++
}

Detecting the latter case requires flow analysis. Currently, we perform flow analysis on all address-of operators, not just to parameters or through "other" functions. This leads to weird behavior:

void h() {
  int i;
  int j = &i;
  i = 1;
  j; // according to our analysis, this has a side-effect: i = 1
  j + j; // reported as unsequenced side-effects
}

Our side effect analysis should be split into two distinct phases: side-effects within expressions, and side-effects from function calls.

It looks like we mostly do this, but incorrectly.

Side-effects within expressions

Should only use flow analysis to find aliases for cases such as:

void f() {
  int i = 0;
  int j = &i;

  int x = i-- + (*j++); // unsequenced effects due to aliasing
}

That is, we can detect that *j is an alias of i and effectively consider the side-effects of i-- + i++. This is different than declaring *j has side-effects.

This is not currently handled correctly, as we inaccurately assign side-effects via localFlow.

Side-effects from function calls
void f(int *x) {
  (*x)++;
}

We should recursively find parameters that become the subjects of side-effects. We should trace parameter x to the effect on x. Now f(x) can be discovered in the above phase as an effect on x -- without flow analysis.

We implement this as AliasParameter, but we don't find local flow from a parameter to its effect, we just look for effects on param.getAnAccess()

Example

Real code example in pandas

      while (*step) {
         stbtt__active_edge * z = *step;
         if (z->ey <= scan_y_top) {
            *step = z->next; // delete from list
            STBTT_assert(z->direction);
            z->direction = 0;
            stbtt__hheap_free(&hh, z);
         } else {
            step = &((*step)->next); // advance through list
         }
      }
主要言語
CodeQL
スター
227
フォーク
82
平均マージ
6日 7時間
マージ済み PR(30日)
9

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/codeql-coding-standards のほかの issue

github/codeql-coding-standards の issue をすべて見る

似ている issue

DevTools の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。