`A5-0-1`: False positive related to overeager alias analysis
まだ誰も着手していません。
評価
調査の方向性
まず SideEffects ライブラリと影響を受ける A5-0-1 分析から始め、次に localFlow と AliasParameter への参照を調べます。提示された例を、式の副作用および関数呼び出しの副作用の扱い(RULE-13-2 のケースを含む)と比較します。エイリアス解析が誤った未順序化の副作用を報告しなくなり、関数パラメーターを介した本物の影響を引き続き検出できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Affected rules
A5-0-1- Likely others such as
RULE-13-2under 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
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
github/codeql-coding-standards のほかの issue
-
false positive/false negative Stardard-MISRA-C++
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
github/codeql-coding-standards#1172 ·
-
Difficulty-Low false positive/false negative false-negative Impact-Low Standard-MISRA-C
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
Difficulty-Medium false positive/false negative false-positive Impact-Medium Standard-CERT-C
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
github/codeql-coding-standards#1200 ·
-
`RULE-0-0-1`: "unreachable statement" false positives due to over-pruning of the control-flow graph オープンfalse positive/false negative
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
github/codeql-coding-standards#1190 ·
-
false positive/false negative
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
github/codeql-coding-standards#1175 ·
github/codeql-coding-standards の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
use-agent-os/agent-os#3314 ·
-
agentic-workflows
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
githubnext/rig#534 ·
-
documentation low-priority templates
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
jesseray718/openroot#87 ·
-
factory-active factory-automatic task-bug-reproduction-cannot-reproduce task-identify-harness-labels-done task-identify-issue-type-done
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
ReedClanton/NixOS#41 ·