On Apr 20, 2011, at 10:56 PM, Jim Goodnow II wrote: > Ok, so the key difference in the static analyzer is run-time actions as > opposed to compile-time choices.
Yes, that's one way to look at it. SVals represent the abstract "semantics" of an expression. Essentially think of the static analyzer as a symbolic simulator for C. > It still seems like there could be a run-time situation where you cared about > the difference between a zero-valued pointer and a 'null' pointer. But, in > reality, I'm guessing that the 'nullptr' type would still be implemented as a > zero-valued pointer, although it could be anything including 0xDEADBEEF! As Argiris pointed out in his email, I don't think that is ever the case. > And cases where a zero valued pointer is an intended use, such as the > offsetof() macro, In this case, I think nullptr would likely be casted first to the pointer of the appropriate type. > would be unlikely enough to be passed a 'nullptr' that it's not worth > modeling? If we care about nullptr, we can locally walk the AST to see if a null value arose from a nullptr. Modeling the semantics specially seems to have no real value.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
