[cfe-dev] fix for Clang PR 8419

[Ted Kremenek]

On Nov 19, 2010, at 5:24 PM, Zhanyong Wan (λx.x x) wrote:

> I'll try that.
> 
> One question: for the purpose of the CFG builder, does an LValue have
> to be mutable?  For example, given
> 
>  void Foo(const Bar& x) { ... }
>  Bar& GetBar() { ... }
> 
> when the analyzer sees "Foo(GetBar());", should it treat "GetBar()" as
> an LValue or RValue?

In all cases, the result of GetBar() is an lvalue (because it returns a reference type).  However, the question is whether or not the parent expression expects an lvalue or an rvalue.  In this case it expects an lvalue, so no lvalue-to-rvalue conversion is necessary.

>  What if the implementation of Foo() actually
> cares about the identity of the input, e.g.
> 
>  void Foo(const Bar& x) {
>    if (&x == &someGlobalBarVairalbe)
>      ...;
>  }


This raises other topics.  Assuming we can lvalue and rvalue semantics correct, this is more about how to we reason about the addresses of memory as well as how do we reason about function calls.  For the former, memory locations are represented using "memory regions" (MemRegion.h), which can represent abstract chunks of memory.  For the latter, we have a variety of choices.  Currently we analyze functions independently (intra-procedurally), but we also have the option to analyze functions inter-procedurally either using inlining (which we have prototyped) or function summaries (something still to do).