[cfe-commits] null pointer literals, warnings, and fixups

[Douglas Gregor]

On Sep 9, 2011, at 10:51 PM, David Blaikie wrote:

> 
> 
> On Wed, Sep 7, 2011 at 3:29 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> On Aug 30, 2011, at 7:37 PM, David Blaikie wrote:
>> 
>> > 2) adds a fixup for this warning in C++0x to suggest using nullptr
>> >
>> > I think there's still a bunch of things worth discussing about when to
>> > suggest nullptr and what to suggest in C++98 (0, NULL, nothing at
>> > all?) & I'd like to apply this kind of suggestion/fixup in a much more
>> > general way (to all null pointer literals that aren't nullptr, not
>> > just the false boolean literal) - but I thought this might be a
>> > moderately easy experiment, even if it's throwaway, and might be a
>> > more concrete thing to start such discussions.
>> 
>> 
>> Seems like we should suggest nullptr, NULL, or 0, depending on which dialect we're in, as we've done elsewhere.
>> 
>> Agreed - I hadn't seen the smarts to do this when I sent this patch out, & I stumbled across it in the uninitialized variable case afterwards. 
>> 
>> I've put a public utility function in Sema to produce a StringRef of the appropriate null pointer literal & used that in both cases.
> 
> 
>> Looking at other similar cases I came across a case in ~line 250, SemaExpr.cpp - handling missing null sentinel nodes (in ObjC/C++ I assume). I don't fully understand the last case there, though - that chooses between "0" and "0L". Also, this seems inconsistent with the (matching) null case in SemaCodeComplete.cpp which suggests "nil", "NULL", or "(void*)0".
> 
> Ick. The reason for 0L is that, when we're dealing with C-style varargs, we need to make sure that the 0 value we suggest is the same length as a pointer. It would be good to give getNullPointerLiteral() the ability to produce 0L when needed, perhaps with a configuration option.
> 
> Oh, tricky. In that case we can't reliably suggest a non-macro null pointer literal then, can we? Because then the code would be non-portable between 64 and 32 bit (etc) builds. 
> 
> That sort of leaves the (void*)0 as the 'right' solution for a portable, size-appropriate, non-macro'd, non-C++0x literal. Or is there another way?

I don't know of any other way. When we're dealing with sentinels, (void*)0 is a fine fallback.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110912/dd24c865/attachment.html>