On Dec 17, 2013, at 7:39 , Gabor Kozar <[email protected]> wrote: > I think a NULL initial state means a checker has decided not to analyze > this function. Weird and unlikely, but possible. (For example, it allows > us to move the -analyze-function option into a checker.) > > Allowing a checker to make this decision on behalf of all the other > checkers... I'm not absolutely certain I like that idea. > 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. > > 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. > > I'll think some more about this, but for the time being I would disallow > NULLs from checkInitialState. 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.
Another option would be to allow checkers to start multiple states with addTransition. In that case, a checker could deliberately, say, test a function with various sensible inputs, rather than purely unconstrained ones. > I'm not sold on this one yet. I mean, I get the idea, but it again seems > like something where we want a nicer interface than just "FunctionDecl" > (and at the very least need to handle ObjCMethodDecl as well). But we can > discuss this later. > > 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. > What do you think? 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. > Finally, style notes (guessing this comes from bouncing between projects): > > 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. > 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? Yes. We're not actively reformatting existing code, but new code should pretty much just follow the LLVM style. Thanks! Jordan
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
