[analyzer] VisitIncDecOp store

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[analyzer] VisitIncDecOp store

Leonard Chan via cfe-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] VisitIncDecOp store

Leonard Chan via cfe-dev
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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] VisitIncDecOp store

Leonard Chan via cfe-dev
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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

smime.p7s (7K) Download Attachment