getAChild*() not returning all children

[gsingh93]

Asking a question about this instead of filing an issue because I have a feeling I'm misunderstanding how this is supposed to work.

I have a C file like this:

void test() {
  char buf[8];
  int j = 0;
  for (int i = 0; i < sizeof(buf); i++) {
    buf[j++] = i;
  }
}

I run this query:

from ForStmt fs
select fs, fs.getAChild*()

I get back this:

1 | for(...;...;...) ... | for(...;...;...) ...
2 | for(...;...;...) ... | ... < ...
3 | for(...;...;...) ... | ExprStmt
4 | for(...;...;...) ... | ... = ...
5 | for(...;...;...) ... | { ... }
6 | for(...;...;...) ... | declaration
7 | for(...;...;...) ... | ... ++

While it's a little hard to read, it should be clear that while it returns the AssignExpr buf[j++] = i (result 4), it doesn't return any of the children of that AssignExpr. Those children definitely exist, as demonstrated by this query:

from AssignExpr ae
select ae, ae.getAChild()

Which returns

1 | ... = ... | access to array
2 | ... = ... | i

as expected.

Is this a bug or am I misunderstanding how getAChild*() works? I would expect that getAChild*() would return all children, including the access to the array and the variable i.

[hvitved]

The problem here is that Expr::getAChild and Stmt::getAChild are actually two different predicates. So when you take the transitive closure of Stmt::getAChild, then it will not include Expr::getAChild.

What you can do is write your own getAChild predicate

StmtParent getAChild(StmtParent p) {
  result = p.(Expr).getAChild()
  or
  result = p.(Stmt).getAChild()
}

and then take the transitive reflexive closure of that.

[hvitved]

Yes.

[gsingh93]

This is a common issue for me, I need this predicate often. Can we add this to the standard library? I can work on a PR if it makes sense to add this.

[hvitved]

@github/codeql-c what do you think?

[MathiasVP]

getAChild really isn't something you should be needing that often. Can you describe the use-cases that keep popping up which require a transitive closure over getAChild? Unless you're lucky with compiler optimizations, the result is always an enormous table that won't perform well.

[gsingh93]

It might be true that there are better ways to do the things I used getAChild* for, but at the very least it's been faster for me to write queries using it without worrying if the pattern I'm looking for is not a direct child of the object I have, but some sub-expression of it. For example:

• If I want to find any pointer dereference where the dereferenced pointer is derived from a pointer obj, I need to handle various cases like*obj, *(obj + 1), *(get_another_pointer(obj) + 1), etc.
• Similarly, I want to find if a variable is used anywhere in the arguments of a function call, like x in malloc((x * sizeof(foo_t)) + sizeof(uint32_t))
• I've done something similar to see if a variable is used in a initializer or assignment, like int a = (x * sizeof(foo_t)) + sizeof(uint32_t)
• In this question, I used it to extract function pointers from nested AggregateLiterals
• I sometimes want to do things where I see if a variable is referenced in two places. For example, I might do a query that checks if the variable x is used in both the condition of an if-statement as well as the body of it: if (x < 4) foo(x). A quick ifStmt.getCondition().getAChild*() is convenient here.
  • Seeing if something appears in the body of a block statement is probably the main use case I have for the function in this question that works on StmtParent. In this if-statement example, using getAChild*(ifStmt) is a quick way of seeing if something is in the body of the statement. My first attempts with this used the existing getAChild*(), and my confusion about what was going on is actually what led me to ask this question
  • I've used similar patterns with for loops and while loops and had some success
  • I've attempted to do this using getEnclosingBlock or getEnclosingElement, but I never got those solutions to work, and I didn't bother digging into it because getAChild*() was working.
  • It might be the case that GuardConditions would actually work better here, but in my limited experience with them I've found them to be slow and poorly documented, so I've just stuck with the quick solution of getAChild*()

In most cases where I do know what the better approach is, at the very least I find it useful to sometimes start with getAChild*() to get some example results to know what variations of the pattern I'm trying to detect are, and then maybe narrowing the results down with a more precise solution.