<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 17, 2013, at 7:39 , Gabor Kozar <<a href="mailto:kozargabor@gmail.com">kozargabor@gmail.com</a>> wrote: </div><blockquote type="cite"><div>
<blockquote><div>I think a NULL initial state means a checker has decided not to analyze<br></div>
<div>this function. Weird and unlikely, but possible. (For example, it allows<br></div>
<div>us to move the -analyze-function option into a checker.)<br></div>
</blockquote><div> </div>
<div>Allowing a checker to make this decision on behalf of all the other checkers... I'm not absolutely certain I like that idea.<br></div>
<div>It
would indeed allow -analyze-function to become a checker, but I would
consider that a hack: conceptually, I wouldn't consider this the job of a
checker.<br></div>
<div> </div>
<div>Besides -analyze-function, what
would this enable? The only other thing I can think of is forcing the
analyzer off code paths that are somehow known to the checker to be
impossible. (I'm talking about allowing a checker to set a NULL state in
general, not just in checkInitialState). That might be practical, I can
imagine some uses, but it would also require considerably more effort
than this.<br></div>
<div> </div>
<div>I'll think some more about this, but for the time being I would disallow NULLs from checkInitialState.<br></div>
<div></div><blockquote></blockquote></div></blockquote><div>It's more just that banning NULL seems like extra work that's inconsistent with most of the other checkers that return a single ProgramState.</div><div><br></div><div>Another option would be to allow checkers to start <i>multiple</i> states with addTransition. In that case, a checker could deliberately, say, test a function with various sensible inputs, rather than purely unconstrained ones.</div><div><br></div><blockquote type="cite"><div>
<blockquote><div>I'm not sold on this one yet. I mean, I get the idea, but it again seems<br></div>
<div>like something where we want a nicer interface than just "FunctionDecl"<br></div>
<div>(and at the very least need to handle ObjCMethodDecl as well). But we can<br></div>
<div>discuss this later.<br></div>
</blockquote><div id="sig19426269"><div class="signature"> </div>
<div class="signature">Also
taking ObjCMethodDecl and BlockDecl into consideration, I'd say lets
create an EntryPointInfo class, that would basically just wrap a
PointerUnion3 (as an internal implementation detail), but would provide
more straightforward accessor methods like getDecl, getFunctionDecl,
getBlockDecl, as well as a get<T> and is<T>. This could also
be generalized and put to use in checkInitialState, and even in
CallEvent - I believe all we have right now is a const Decl* getDecl()
there.<br></div>
<div class="signature">What do you think?<br></div>
<div class="signature"></div></div><blockquote></blockquote></div></blockquote><div>CallEvent's getDecl is overridden to return more specific Decls in its subclasses, but for checkInitialState EntryPointInfo seems like a good idea. We may end up wanting to put other things in there as well.</div><br><blockquote type="cite"><div><blockquote><div id="sig19426269">Finally, style notes (guessing this comes from bouncing between projects):<br></div>
</blockquote><div> </div>
<div class="signature">Yeah,
in general, I tried to use the style I saw in the surrounding code, but
I did not really pay attention to this. Will definitely fix it, thanks
for pointing it out.<br></div>
<div class="signature">At work, we're
using clang-format to take care of these issues for us. I guess I can
also set it up for when I'm working on Clang. You're using the LLVM
style, right?<br></div></div></blockquote><div><br></div><div>Yes. We're not actively reformatting existing code, but new code should pretty much just follow the LLVM style.</div><div><br></div><div>Thanks!</div><div>Jordan</div></div></body></html>