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

Aberta
#1,047 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
cpp
Domínio
devtools

Direção de pesquisa

Comece pela biblioteca SideEffects e pela análise A5-0-1 afetada; em seguida, inspecione as referências a localFlow e AliasParameter. Compare os exemplos fornecidos com o tratamento dos efeitos colaterais de expressões e dos efeitos colaterais de chamadas de função, incluindo o caso RULE-13-2. O trabalho estará concluído quando a análise de alias deixar de relatar efeitos colaterais não sequenciados falsos e continuar detectando efeitos genuínos por meio de parâmetros de função.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
         }
      }
Linguagem predominante
CodeQL
Estrelas
227
Forks
82
Merge médio
6d 7h
PRs com merge (30d)
9

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/codeql-coding-standards

Todas as issues de github/codeql-coding-standards

Issues semelhantes

Mais issues de DevTools

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.