[cfe-commits] [PATCH][Review request]Support for c++0x nullptr in static analyzer

[Argyrios Kyrtzidis]

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
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits