[cfe-dev] fix for Clang PR 8419

[Ted Kremenek]

Yes, that seems reasonable to me.

On Nov 19, 2010, at 11:35 PM, Zhongxing Xu wrote:

> While fix the lvalue-rvalue conversion issue in the AST seems to bring benefits in the long run, I suggest we fix these cases one by one in the CFG construction, until we see enough cases that warrants an overhaul.
> 
> In this case, we can only mark the block-level expr in the unary operator as StatementAsLValue. This is a simple and local change.
> 
> 2010/11/20 Zhanyong Wan (λx.x x) <wan at google.com>
> Thanks for thinking through this and sharing your analysis, Ted!  I'm
> all for fixing this in a principled way.  However, the crash I
> reported is blocking some experiments I'm doing.  Therefore I'd really
> like to put in a fix for the symptom first to unblock me, and then we
> can take the time necessary to fix the whole thing the right way.
> Would you oppose to that?  Thanks,
> 
> On Fri, Nov 19, 2010 at 11:07 PM, Ted Kremenek <kremenek at apple.com> wrote:
> > On Nov 19, 2010, at 5:24 PM, Zhanyong Wan (λx.x x) wrote:
> >
> >> I'll document this in my new patch.  Also, how would you suggest to
> >> add a test to catch violation of #2?
> >
> > Stepping back, I think we may need some extra design here, either in the ASTs or in the analyzer, to model lvalue-to-rvalue conversions correctly for C++.
> >
> > With C, lvalue-to-rvalue conversions happen in specific cases, e.g.:
> >
> > - Loading from a variable
> >
> > - Dereferencing a pointer
> >
> > Semantically such conversions result in a "load" of a value from a memory address.  This is what 'EvalLoad()' does in GRExprEngine.  Because the places where such conversions occur in C are fairly limited, up to now we have been able to model lvalue-to-rvalue conversions without much effort.
> >
> > With C++ (especially with the use of references) there is a lot more cases to reason about.  It raises the question of whether we should try to recreate the logic in codegen in GRExprEngine to infer all of these cases, or to try and represent them explicitly in the AST.
> >
> > There are advantages to representing such conversions explicitly in the AST.  For one, the distinction of an lvalue versus an rvalue in the CFG probably evaporates.  Any place where we see an lvalue-to-rvalue conversion simply means the subexpression was a pointer (or reference), and the conversion represents a load.  Moreover, different analyses (not just GRExprEngine) will be able to more adeptly reason about the semantics of analyzed code without having the burden to re-infer where all the lvalue-to-rvalue conversions take place.
> >
> > The other advantage is that it takes care of discrepanancies between C and C++ like the following:
> >
> > $ cat t.c
> > void foo() {
> >  int a = 0;
> >  ++(++a);
> > }
> >
> > $ clang -fsyntax-only t.c
> > t.c:3:3: error: expression is not assignable
> >  ++(++a);
> >  ^ ~~~~~
> > 1 error generated.
> >
> > $ clang -fsyntax-only -x c++ t.c
> > $
> >
> > Here C and C++ differ on the semantics of '++'.  When the file is compiled as C code, we get an error because the expression '++a' evaluates to an rvalue.  When we compile the code as C++, however, the expression evaluate to an lvalue.  This difference isn't represented in the AST at all.
> >
> > NOTE: This is also another reason why GRExprEngine might crash in some cases with '++' on C++ code, because it assumes the C semantics.
> >
> > To explain the difference some more, consider:
> >
> >  int a = 0;
> >  int b = ++a;
> >
> > With C, the '++a' evaluates to an rvalue immediately, which is assigned to 'b'.  In C++, the expression '++a' first evaluates to an lvalue, and then there is an implicit lvalue-to-rvalue conversion that loads the new value.  Of course the compiler doesn't need to generate more IR to represent this at the execution level, but this is what is conceptually happening in the language.
> >
> > So to summarize, these discrepancies of how lvalues and rvalues are reasoned about in C versus C++ is really something we need to solve systematically in the analyzer (and/or ASTs) with a cohesive solution.  That's why I think this individual case that you reported is only symptomatic of a bigger issue that needs a well-designed solution.
> >
> > Cheers,
> > Ted
> 
> 
> 
> --
> Zhanyong
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101120/f765439b/attachment.html>