On Apr 20, 2011, at 10:56 PM, Jim Goodnow II wrote: > 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?
It seems to me that the standard does indeed specify that 'nullptr' type is a zero-valued pointer, see 4.1p2: "if the glvalue has (possibly cv-qualified) type std::nullptr_t, the prvalue result is a null pointer constant" There may be cases where one may want to check that nullptr is used instead of a '0', e.g. to enforce nullptr usage but one can check the AST directly for that, I don't think there's much usefulness in trying to distinguish at runtime. > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
