[cfe-dev] [analyzer] VisitIncDecOp store

Rafael·Stahl via cfe-dev cfe-dev at lists.llvm.org
Mon Apr 9 00:23:47 PDT 2018

The SVal argument of checkLocation is a loc::ConcreteInt and has the 
value of the pointer p in my example. This is some address and seems 
correct (it is statically determinable). The only thing that seems 
inconsistent/misleading is that the Stmt argument of checkLocation is 
pointing to the IncDecOp instead of the dereference.

On 08.04.2018 01:12, Artem Dergachev wrote:
> Looks like a bug, yeah. Though it's probable that some checkers have 
> already "adapted" to it.
> That said, a non-pointer prvalue expression that has a value of 
> loc::ConcreteInt kind sounds like a bigger bug (regardless of whether 
> it's the expression that we're looking for). Is it the value that was 
> supplied in the callback, or is it the actual value of the unary 
> operator expression (i.e. `State->getSVal(UnaryOp, LCtx)`)?
> On 4/6/18 4:56 AM, Rafael·Stahl via cfe-dev wrote:
>> Hi,
>> While developing a checker I have noticed that in the checkLocation 
>> callback I received an unexpected Expr. It was an UnaryOperator of 
>> non-pointer type and its SVal was a loc::ConcreteInt which doesn't 
>> really make sense in my opinion.
>> When looking into this in ExprEngineC.cpp 
>> ExprEngine::VisitIncrementDecrementOperator I noticed that the calls 
>> to evalStore pass the whole UnaryOperator Expr as third argument 
>> LocationE. This LocationE is documented as "The location expression 
>> that is stored to". I would have understood this as the 
>> sub-expression of the UnaryOp instead of the Op itself.
>> In particular:
>> -evalStore(Dst3, U, U, ...);
>> +evalStore(Dst3, U, Ex, ...);
>> Example:
>> volatile int *p;
>> (*p)++;
>> UnaryOperator 0x1bad960 'int' postfix '++'
>> `-ParenExpr 0x1bad940 'volatile int' lvalue
>>   `-UnaryOperator 0x1bad920 'volatile int' lvalue prefix '*' cannot 
>> overflow
>>     `-ImplicitCastExpr 0x1bad908 'volatile int *' <LValueToRValue>
>>       `-DeclRefExpr 0x1bad8e0 'volatile int *' lvalue Var 0x1bad320 
>> 'p' 'volatile int *'
>> Here the outer UnaryOp is passed as SVal in checkLocation instead of 
>> the inner one.
>> Is my understanding correct? In that case I'm able to submit a patch.
>> Best regards
>> Rafael
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180409/5fb7cd81/attachment.bin>

More information about the cfe-dev mailing list