[cfe-dev] Removing "TransferFuncs" from the analyzer

[Jordy Rose]

On Jul 15, 2011, at 8:13, Ted Kremenek wrote:

> 
> On Jul 15, 2011, at 1:11 AM, Jordy Rose wrote:
> 
>>> In the absence of symbol unification, however, we can probably special case the aliasing issue, at least for this specific case. For example, we can create another (perhaps transient) Checker callback that asks: does this function/method return an alias? Then ExprEngine can get in the business of doing the aliasing, and the checker just handles the truly checker-specific stuff (e.g., the reference counts).
>> 
>> That seems like a very specific check that would only be useful until we got a [[return_alias]] attribute, then got it into all the frameworks. :-) But it would solve the problem.
> 
> Just to pull this one out with a brief comment: this isn't specific to checkers.  For example, if we see:
> 
>   void foo(int *a, int *b) {
>      …
>      if (a == b) {
>        …
>      }
>   }
> 
> We currently don't have a good way to reason about the case where "a == b".  If we have acquired constraints on the symbols referenced by 'a' and 'b', then they have to be unified on the true branch (and if the constraints are incompatible, the branch is infeasible).  This pops up more times than one might think.
> 
> I agree that this is something to explore as a separate discussion in its own right, but it is a key piece of missing analyzer functionality.

Oh, yes, aliasing is very important. Whether or not a specific function/method call returns an alias seems less so, since eventually a postCall checker could do that naively with assumeEQ. But I suppose "eventually" might be "in a month" or it might be "years from now when someone else is looking for a GSoC project", so maybe a temporary returnsArgAlias check is better than a temporary evalObjCMessage check.