On 4/20/2011 5:30 PM, Ted Kremenek wrote: > On Apr 20, 2011, at 4:47 PM, Joerg Sonnenberger wrote: > >> On Wed, Apr 20, 2011 at 03:52:55PM -0700, Jim Goodnow II wrote: >>> Hi Ted, >>> >>> Yes, we do. The real purpose of the nullptr is the last part of the test >>> program where it allows you to distinguish between two overloaded >>> functions, i.e.: >>> >>> void func( int ); >>> void func( int *); >> I don't see how it matters here. But what about classic variadic >> functions? nullptr is a valid sentinal for execl, NULL isn't. > This isn't an issue for the static analyzer either. This is purely a concept > that Sema has to worry about. > > SVals represent the abstract values, often in the absence of types. In this > case, a C++ nullptr is just a location type with a value of 0. That's what a > loc::ConcreteInt (with value 0) represents. It's up to Sema to reason about > type conversions, etc. The analyzer doesn't need to worry about them (in > most case). In the analyzer's case, all we care about is that *semantically* > nullptr evaluates to a null address. > > Jim: I think nullptr_t probably doesn't require any more work in the analyzer > other than (1) adding an entry to Environment::getSVal(), similarly to how we > handle IntegerLiteralClass and (2) moving the case in ExprEngine::Visit() for > CXXNullPtrLiteralExprClass to be in the same cases as we have for > IntegerLiteralClass and friends. > Ok, so the key difference in the static analyzer is run-time actions as opposed to compile-time choices. 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! And cases where a zero valued pointer is an intended use, such as the offsetof() macro, would be unlikely enough to be passed a 'nullptr' that it's not worth modelling?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
