[cfe-dev] [StaticAnalyzer] How to allocate SymbolRef for values passed through function parameters

[Haowei Wu via cfe-dev]

Hi,

I am new to clang and I am developing a checker to detect resource leaks
that is similar to the SimpleStreamChecker except that the target function
is passing its return value through parameters. The example code would be
like:

int request(int * arg1, int * arg2);
int release(int arg1);
void foo() {
   int fd1 = 0, fd2 = 0;

   request(&fd1, &fd2);

   // ..... some unrelated code

   release(fd1);
   release(fd2);
}


Here, the integer fd1 and fd2 are resource descriptors that should be
assigned with unique integer values after the "request(&fd1, &fd2)" call.
The resource will be leaked if someone forgot to call "release(fd)" on a
resource descriptor.

The problem is , if I use the "Call.getArgSVal(0)" on the calls to  the
"release(fd1)" or "release(fd2)"  function, I only get a "ConcreteInt"
which is the value "0" that I assigned in the initializer instead of a SVal
with a SymbolRef. In this case, I cannot determine if the value in "fd1" is
the same value that is assigned after the call to the "request(&fd1, &fd2)".

The original SimpleStreamChecker does not have this issue because the file
descriptor (to be precise, it is FILE *) used in "FILE *F =
fopen("mylog.txt", "w");" is passed through the return value instead of
parameter. In this case, clang will allocate a SymbolRef for "F". And it
will be the same one if I call "Call.getReturnValue().getAsSymbol()" on a
"fclose(F)".

My question is, is there anyway to allocate SymbolRef to the variables
pointed by arg1 and arg2 manually in the checkPreCall for the "int
request(int * arg1, int * arg2)"? So in checkPostCall for "int release(int
arg1);" I can use "Call.getReturnValue().getAsSymbol()" to check if the
SymbolRef of "arg1" is the same one that allocated in "int request(int *
arg1, int * arg2)"?

Thanks for any help,
Haowei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170522/16c3f68b/attachment.html>