<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 30, 2011, at 7:37 PM, David Blaikie wrote:</div><blockquote type="cite"><div class="gmail_quote">On Mon, Aug 29, 2011 at 5:46 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On Aug 21, 2011, at 9:18 PM, David Blaikie wrote:<br>
<br>
> As a small indirect first attempt I've included a patch that:<br>
><br>
> 1) changes "NULL" to "null" in "initialization of pointer of type %0<br>
> to NULL from a constant boolean expression" - since NULL is a specific<br>
> macro but the general concept is simply a "null pointer".<br>
<br>
</div>Looks good.<br></blockquote><div><br>Hmm - I see you checked in the fixit fix, but not this text change. Was there a reason? Good thing in any case, since I'd failed to update the tests. The attached patch includes the updated tests.<br></div></div></blockquote><div><br></div>I... think there was some redundancy in messages that confused me. The change to the message text is good.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>[though these test cases surprise me a bit - I hadn't realized that any integral zero constant (not just literals) were valid null pointer literals. Sounds like another case for a warning. Seems unlikely anyone's legitimately writing "const int null = 0; int* i = null;" are they? Well, I'll see about handling that in the overall/whitelisting way. Accept zero integer literals, NULL, and nullptr as null pointers & warn on anything else]<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> 2) adds a fixup for this warning in C++0x to suggest using nullptr<br>
><br>
> I think there's still a bunch of things worth discussing about when to<br>
> suggest nullptr and what to suggest in C++98 (0, NULL, nothing at<br>
> all?) & I'd like to apply this kind of suggestion/fixup in a much more<br>
> general way (to all null pointer literals that aren't nullptr, not<br>
> just the false boolean literal) - but I thought this might be a<br>
> moderately easy experiment, even if it's throwaway, and might be a<br>
> more concrete thing to start such discussions.<br>
<br>
<br>
</div>Seems like we should suggest nullptr, NULL, or 0, depending on which dialect we're in, as we've done elsewhere.<br></blockquote><div><br></div><div>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. <br>
<br>I've put a public utility function in Sema to produce a StringRef of the appropriate null pointer literal & used that in both cases.</div></div></blockquote></div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div>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".<br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>What would be the right set of suggestions for null pointer literals across all clang languages (C needs the cast (or NULL), objc prefers nil over NULL - should it prefer nil over nullptr in C++0x? (nil > nullptr > NULL > 0))?<br></div></div></blockquote><br></div><div>nil > nullptr > NULL > 0 is reasonable.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>