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

[David Blaikie]

On Mon, Sep 12, 2011 at 9:47 AM, John McCall <rjmccall at apple.com> wrote:

> On Sep 12, 2011, at 8:14 AM, Douglas Gregor wrote:
>
> 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.
>
>
> Note that that code has actually changed and does not attempt to use 0 or
> 0L anymore, because the actual sentinel-checking code intentionally only
> matches expressions of pointer type.
>

Oh, OK - great. (revision 139352, I see)

So in general we'll prefer nil > (NULL | nullptr) > 0 for normal cases and
nil > (NULL | nullptr) > (void*)0 for this particular case of null
terminated varargs. I'll see what I can generalize out of all of this (&
potentially get the case in SemaCodeComplete.cpp using such common
infrastructure too)

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