[cfe-dev] [analyzer] Evaluating a call to operator bool()

[via cfe-dev]

On Fri, Jan 10, 2020 at 10:47 PM Artem Dergachev <noqnoqneo at gmail.com>
wrote:

> Operator bool() is never invoked in your code. The body of the operator
> is analyzed separately, outside of any known context (call site). For
> that reason you get a "symbolic region" for it, which is a notation for
> the memory region around a pointer that isn't known to point into any
> specific memory location on the current execution path (in this case,
> it's the pointer 'this' during the unknown invocation of operator
> bool()). A symbolic region is always an alias for a particular
> "concrete" region, it's simply not known *which* one; it may or may not
> be the struct you've constructed in your other function.
>

OK, got it, I think I understand now that looking at operator bool() is a
red herring in my case. What I'm trying to do is to see whether, at the end
of any path through the function, the pointer in MyStruct is known to be
null or known to be non-null. Not sure why I had convinced myself that
operator bool() would be called in that situation ... :-) So maybe I should
actually be able to achieve this by just consulting the program state map
at the exit point of the function.

Studying the static analyzer by printing values to standard output may
> get very confusing because the analyzer doesn't explore the program in
> any particular linear order. Analysis is much better represented as a
> graph which can be easily dumped
> (https://www.youtube.com/watch?v=g0Mqx1niUi0). If you want to debug your
> checker this way, you should implement the "printState()" method in the
> checker, so that to see the extra information from it in the graph.
>

Can I do this without compiling my own clang and llvm? I have tried to
figure out how to dump the graph before, but I thought I ran into the
problem of having to have a debug-enabled copy of clang.

By the way, these talk videos you've sent have really been quite useful,
and I think they'd be prime candidates for turning into documentation or
blog posts! I haven't yet found time to watch them all the way through, but
documentation would be searchable and browseable :-)


> On 1/11/20 9:05 AM, philip.chimento at gmail.com wrote:
> > On Wed, Jan 1, 2020 at 11:57 AM Artem Dergachev <noqnoqneo at gmail.com
> > <mailto:noqnoqneo at gmail.com>> wrote:
> >
> >     On 12/30/19 7:55 PM, philip.chimento at gmail.com
> >     <mailto:philip.chimento at gmail.com> wrote:
> >     > However, the returned region seems to be different in the
> >     constructor
> >     > and in the get() method. For example I'm testing my code with a
> >     > "struct MyStruct : std::unique_ptr<char>" and I'll get debug output
> >     > such as:
> >     >
> >     >     constructor: Storing 0 (Loc) into map with key
> >     > SymRegion{conj_$5{struct MyStruct *, LC1, S3038538, #1}}
> >     >     get(): Retrieving key SymRegion{reg_$0<const struct MyStruct *
> >     > this>}: not present
> >     That sounds strange because i think i fixed most of these problems
> >     (https://www.youtube.com/watch?v=4n3l-ZcDJNY). Can you post the
> >     specific
> >     code you're trying to analyze? Is your Clang fresh enough?
> >
> >
> > I'm using 9.0.0, would this be something that I need to build the
> > master branch for?
> >
> > The test code I'm trying to analyze is this:
> >
> > struct Context;
> > char* StringFunc(Context* cx);
> >
> > struct MyStruct : public std::unique_ptr<char> {
> >     MyStruct(char* p) : MyStruct::unique_ptr(p) {}
> >     operator bool() const { return !!get(); }
> > };
> >
> > MyStruct OkayBoolConvertibleReturn(Context* cx) {
> >     char* ptr = StringFunc(cx);
> >     if (ptr)
> >         return ptr;
> >     return nullptr;
> > }
> >
> > Cheers,
> > --
> > Philip
>
>
Cheers,
-- 
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200120/7b02e88b/attachment.html>