C++: codeql seemingly returning wrong Expr

[hugeh0ge]

See the following C++ and codeql code:

#include <cstdio>

struct Test {
  const char * operator()() const {
    return "Hello, World!";
  }
};

void f(Test st) {
  puts(st());
}

int main() {
  f(Test());
}

from Function func, FunctionCall fc
where func.getName().matches("f")
  and fc.getTarget() = func
select fc, fc.getArgument(0)

When I query the C++ code, codeql says the argument of FunctionCall is 0 instead of an instance of struct Test.
Is this a bug? Or some intended behavior?

[geoffw0]

Thank you for bringing this to our attention,

As written the argument to f comes out as a Literal value 0 of type Test. This does indeed look quite strange.

Even if I give Test a constructor, I get a ConstructorCall "call to Test" of type void. I believe the type here should be Test.

I'll ping some people and see if anyone knows what's going on.

[jbj]

We think this bug has the same underlying cause as #4105. We're going to investigate how to better represent temporaries in the database.

[jbj]

We're working on this as part of a larger effort to model temporaries properly in the database and libraries. We'll keep you posted.

[hugeh0ge]

I appreciate your team's honest and kind response!
As I use codeql more deeply, I notice some bugs or incomplete parts of codeql, and that hence codeql is developing and I should wait it. As one of users believing it is a promising tools, I would like to help its improvement.

[dbartol]

Now that we've implemented the change to explicitly represent temporary objects in the AST, I've taken another look at this issue. This issue actually doesn't have much to do with temporary objects; it's actually about how we represent a T() expression, where T is a type name.

Test() produces a temporary object of Test, initialized by zero-initialization. We represent the zero-initialization as a Literal node in the AST, with the correct type (Test), and with the value 0 to represent the zero-initialization. I can see how this could be confusing, and I've opened github/codeql-c-team#2863 to consider other ways to represent this.

The representation of zero-initialized classes hasn't changed with the new temporaries support. What did change is that if you call fc.getArgument(0).getConversion(), you'll now get a TemporaryObjectExpr that represents the temporary object itself, with the Literal node serving as the initializer of the temporary object. I'm not sure that's important to your case, though.